JWT Security Analyzer

Go past decoding a JWT: check the algorithm, the registered claims, issuer and audience, lifetimes and key references against the mistakes that make tokens forgeable.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

JSON Web Token Decoded and analysed in your browser. A Bearer prefix is fine.

A token is not a secret, and decoding one proves nothing

Both halves of that sentence catch people out. The payload of a JWT is base64, not encryption - anyone holding the token reads it, which is why putting a password or an API key in a claim is publishing it. And reading a token tells you only what its bearer chose to put there: the header and payload can be rewritten by anyone, so an unverified role: admin means nothing at all.

This page reads. It does not verify. That is deliberate - the two are separate jobs and conflating them is how people end up trusting claims they never checked. Use the JWT Signature Verifier with the issuer's key for the other half.

What it looks for

alg: none. The original JWT vulnerability: a token that declares no signature, accepted by any verifier that takes the algorithm from the token. Graded critical, because it means anyone can write the payload.
Algorithm confusion. When a token is HMAC-signed, a verifier that also accepts RS256 can be attacked by using the public RSA key - which is public - as the HMAC secret. Whether that applies depends on the verifier, not the token, so it is reported as Unknown rather than asserted.
Key-fetching headers. jku and x5u tell the verifier where to get the key; jwk and x5c embed it outright. All four are attacker-controlled input, and a verifier that honours them is checking the signature against a key the attacker supplied.
kid injection. Key identifiers get concatenated into file paths and SQL more often than anyone would like. Traversal sequences and quote characters are flagged.
Claims. Missing exp, iss, aud, sub and jti; lifetimes measured in days rather than minutes; and exp emitted as a string, which different libraries read as zero or as never.
Credentials and personal data in the payload, since the payload is readable by every proxy and log the token passes through.

Why the severities are phrased the way they are

A JWT is not insecure by itself - it is a signed string. What is insecure is the code that accepts it. So every finding here is written as what an attacker could do if your verifier behaves the way this token suggests, and the ones that genuinely cannot be determined from a token say Unknown instead of guessing. A tool that reports a certainty it does not have is worse than one that says it does not know.

Nothing is uploaded

A JWT is a credential. Pasting one into a site that posts it to a server hands over whatever it authorises - which is why the decode-a-JWT sites that round-trip to a backend are a genuinely bad idea, however convenient. Everything here happens in your browser, and the exports are generated locally.

Frequently asked questions

Does a clean report mean my token is safe?

It means the token itself carries no obvious defects. Most JWT vulnerabilities live in the verifier, not the token - whether it pins the algorithm, whether it checks the audience, whether it fetches keys from URLs. A clean token in front of a careless verifier is still a problem.

Why won't it verify the signature here too?

Because verifying needs a key you trust, and mixing "here is what the token says" with "here is whether it is genuine" in one output is how people come away thinking they checked something they did not. The verifier is a separate page for that reason.

It flagged my token for having no aud. Is that really a problem?

It depends on whether more than one service trusts your issuer. If two do, a token minted for the low-value one is accepted by the high-value one, and audience is the claim that stops it. With a single service it is defence in depth.

Is my token sent anywhere?

No. It is decoded and analysed in your browser, and the export is generated there too. The export deliberately contains the findings and header rather than the payload, since that is the part likely to hold personal data.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.