JWT Security Analyzer: Decode a Token and Find Its Weaknesses
This free JWT security analyzer decodes a JSON Web Token and checks it for the flaws attackers use: alg none, guessable HS256 secrets, key injection through jku and jwk headers, missing expiry, missing audience, and sensitive data in the payload. Paste a token to read its header and payload, see every finding rated by severity, and get the fix for each. It runs in your browser and the token never leaves it.
- Free
- No signup
- Runs in your browser
- Decodes header and payload
- Weak-secret test
Authorization: Bearer ... header or a cookie value. Press Ctrl+Enter to analyse.How it works
- 1Paste the tokenPaste a JWT, a Bearer header or a cookie value. Add a key if you want the signature checked.
- 2About thirty checks runAlgorithm, header keys, expiry and audience, payload content and the signature, all in your browser.
- 3Fix the findingsEach finding is rated by severity with the reason and the fix, and the worst one sets the rating.
How this JWT security analyzer works
The JWT security analyzer splits the token into its header, payload and signature, decodes the first two, and runs about thirty checks on the algorithm, the header parameters, the time claims, the payload content and the signature. Every problem is rated critical, high, medium, low or info, with a plain explanation and the fix. The overall rating follows the worst finding: Dangerous, Weak, Needs work or Looks sound.
If you enter the secret or the public key, the tool also checks the signature with the Web Crypto API. For HS256, HS384 and HS512 tokens it can test the signature against a list of common secrets. A match means anyone can forge tokens for your users.
What is inside a JWT: decode the header and payload
A JWT (JSON Web Token, RFC 7519) has three base64url parts joined by dots. The header names the signing algorithm and sometimes the key. The payload holds the claims. The signature is created with a secret or a private key. Decoding the first two parts needs no key, so a JWT decoder shows exactly what the token says, but only a signature check shows whether it is genuine.
| Claim | Meaning | Guidance |
|---|---|---|
| iss (issuer) | Who created and signed the token. | Check it matches your identity provider. |
| sub (subject) | Who the token is about, usually a user ID. | Use a stable ID, not an email. |
| aud (audience) | Which service the token is for. | Every service checks it is listed. |
| exp (expiry) | When the token stops being valid. | Required. 5 to 15 minutes for access tokens. |
| nbf (not before) | The earliest time the token is valid. | Optional. |
| iat (issued at) | When the token was created. | Lets you reject old tokens. |
| jti (token ID) | A unique ID for this token. | Enables revocation and replay detection. |
JWT vulnerabilities this tool checks
These are the weaknesses behind most real-world JWT attacks. They are described in RFC 8725 (JSON Web Token Best Current Practices) and in the OWASP JSON Web Token Cheat Sheet, and they fall under broken authentication in the OWASP API Security Top 10.
| Weakness | Why it matters | Fix |
|---|---|---|
| Algorithm none | The token has no signature, so anyone can forge claims. | Reject alg none and pin the accepted algorithms. |
| Weak HMAC secret | A guessable HS256 secret lets anyone sign tokens. | Use a random secret of at least 32 bytes. |
| Algorithm confusion | A server that reads alg from the token can be made to verify an RS256 token as HS256 with the public key as the secret (CVE-2015-9235). | Pin the algorithm on the server. |
| Key injection (jwk, x5c, jku, x5u) | The token tells the server which key to trust (CVE-2018-0114). | Take keys only from your own key store or a fixed JWKS URL. |
| kid injection | A kid used in a file path or SQL query can load an attacker-chosen key. | Treat kid as an opaque ID and match it against a fixed list. |
| Missing or long expiry | A stolen token keeps working for as long as it lives. | Short expiry and refresh tokens. |
| Missing audience or issuer | A token for one service is accepted by another. | Check iss and aud on every service. |
| Sensitive data in the payload | The payload is encoded, not encrypted, so anyone can read it. | Keep secrets out, or encrypt with JWE. |
| Empty or wrong-length signature | A token with its signature stripped is accepted by sloppy servers. | Always verify, and reject empty signatures. |
| Time claims in milliseconds | A value in milliseconds makes the token valid for thousands of years. | JWT times are in seconds. |
How the rating works
The rating is set by the most serious finding. Critical means an attacker can forge or read the token now, for example alg none, a guessable secret, an empty signature or key injection with an embedded key. High covers missing expiry, key-fetch headers, injection-like kid values, secrets in the payload and a signature that does not match. Medium covers weak audience handling and long lifetimes. Low and info are hardening notes. A token that passes every check is rated Looks sound, but that is about the token, not your server. Your server still has to verify the signature, the algorithm, the issuer, the audience and the expiry on every request.
JWT security best practices
Follow these rules when you issue and verify tokens. They come from RFC 8725 and the OWASP guidance.
- Pin the algorithm. Accept only the algorithm you expect and never take it from the token header. Reject alg none.
- Use strong keys. For HS256 use a random secret of at least 32 bytes. For RS256, ES256 or EdDSA keep the private key in a key vault and rotate it.
- Keep tokens short-lived. Use 5 to 15 minutes for access tokens and rotate refresh tokens.
- Validate every claim. Check exp, nbf, iss and aud, and match kid against a fixed key set.
- Do not trust keys in the token. Ignore jwk, x5c, jku and x5u unless they match an allow-list.
- Keep secrets out of the payload. The payload is readable by anyone. Use a JWE if you must encrypt it.
- Store tokens carefully. Prefer HttpOnly, Secure, SameSite cookies over localStorage, so cross-site scripting cannot read them.
- Plan for revocation. Use jti and a deny-list, or short lifetimes, so a leaked token can be stopped.
Where to get your JWT
Open your browser's developer tools and go to the Network tab, click an API request and copy the value after Bearer in the Authorization request header. For a token kept in a cookie or in local storage, open the Application tab. With curl you can print the response and copy the token from it.
curl -s -X POST https://api.example.com/login -d '{"user":"test","pass":"test"}'Then paste the token above. Pair this check with the OpenAPI Security Linter, which finds missing authentication in your API spec, and the API vulnerability scanner, which tests how your API handles forged and expired tokens.
Frequently asked questions
What is a JWT (JSON Web Token)?
A JSON Web Token is a compact string that carries claims about a user or a client, defined in RFC 7519. It has three base64url parts joined by dots: a header that names the signing algorithm, a payload with the claims, and a signature. Servers use JWTs for login sessions and API access. Anyone can decode the first two parts, so a JWT proves who issued it only when its signature is verified.Is it safe to paste a JWT into this tool?
The analysis runs entirely in your browser and the token and key are not sent anywhere. Even so, treat a live JWT like a password. Whoever holds an unexpired token can use it. Paste expired, test or staging tokens where you can, and never paste a production token into a tool you do not trust.Can a JWT be decoded without the secret?
Yes. The header and payload are only base64url encoded, not encrypted, so any JWT decoder can read them without a key. The secret or private key is needed only to create or verify the signature. This is why you should never put passwords, API keys or other secrets in a JWT payload, unless you use an encrypted JWE.What is the alg none attack?
In the alg none attack an attacker changes the header to alg none, removes the signature and edits the claims, for example to become an admin. Libraries that accept tokens with no signature treat them as valid. The fix is to reject alg none and to pin the allowed algorithms on the server instead of reading the algorithm from the token.How do I know if my JWT secret is weak?
If your tokens use HS256, HS384 or HS512, the secret should be at least 32 random bytes, for example from openssl rand -base64 48. Short words, project names and tutorial values such as secret or your-256-bit-secret can be guessed offline in seconds. This tool tests your token against a list of common secrets and reports a match as critical.What is a good expiry time for a JWT?
Access tokens should live for 5 to 15 minutes. Use a longer-lived refresh token, stored more carefully and rotated on each use, to get new access tokens. Short lifetimes limit what an attacker can do with a stolen token. A token with no exp claim never expires and is rated high risk.What is the difference between HS256 and RS256?
HS256 uses one shared secret to sign and verify, so every service that can verify a token can also forge one. RS256 signs with a private key and verifies with a public key, so verifying services cannot create tokens. RS256, ES256 and EdDSA are safer when several services or third parties verify your tokens.What is JWT algorithm confusion?
Algorithm confusion happens when a server trusts the alg in the token header. An attacker takes a token signed with RS256, changes the algorithm to HS256 and signs it using the server's public key as the HMAC secret. A vulnerable library then verifies it with that key. Pin the expected algorithm in your verifier to prevent it.A token is only one part of API security. Test how your API handles forged and expired tokens.
See the API vulnerability scannerSee pricing