JWT Decoder

How to use it

1. 1Paste your text into the box marked "JWT"Paste the whole token, including both dots. Everything happens inside your browser — nothing is uploaded, so there is nothing for us to store, log or lose.
2. 2Read the result as it updatesThere is no button to press. The header and payload decode immediately. The output recomputes every time you change the text or one of the options above it.
3. 3Read the header and the claims separatelyThe header says which algorithm signed it. The payload holds the claims — who the token is for, what it permits, and when it expires. Standard claims are labelled, because iat, nbf and exp are not obvious.
4. 4Check the expiryexp and nbf are shown as readable dates. An expired token is the first thing to rule out when a request that used to work has started returning 401.
5. 5Understand that the signature is NOT verifiedVerifying it needs the secret or public key, and pasting a signing secret into a web page is a bad habit to build even on a tool that runs locally. Decoding proves what a token says, never that it is genuine.
6. 6Treat a decoded token as still sensitiveNothing is uploaded here — but a JWT from a live system is a working credential until it expires, and it should be treated like a password wherever it goes next.
7. 7Copy or download the resultThe buttons under the output put it on your clipboard or save it as a file, and each one says exactly what it will copy or download. Any note about something the tool changed or deliberately left alone is shown with the result rather than hidden.

About this tool

A JSON Web Token carries a header, a set of claims and a signature, joined by full stops. The header and claims are Base64url — encoded, not encrypted — so anyone holding the token can read them. That is what this tool does: it shows you what is inside.

It does not verify the signature, and it will never tell you a token is valid. Verification requires the issuer's secret or public key, which lives on your server and should not be pasted into a web page. A tool that showed a green tick because the JSON parsed would be teaching people to trust a forged token.

Understanding the result

The registered claims are explained where they appear: iss is the issuer, aud is who the token is for, exp is when it should stop being accepted. Custom claims are shown as they are, without a guess at their meaning.

exp, nbf and iat are spelled out as real dates with a relative description. An expired token is described as expired — which is what the token claims, not a statement that any particular server would reject it.

Security observations always include the line that the signature was not checked. alg "none", an empty signature and a key embedded in the header are called out specifically, because each is the basis of a known attack.

Example

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.…

alg: HS256
sub: 1234567890 — Subject, who or what the token is about
▲ The signature was NOT checked.

Limitations

• The signature is not verified and cannot be. A token whose claims read perfectly may be entirely forged.
• An encrypted token — a JWE, in five parts — cannot be read at all without the decryption key. The tool says so rather than failing obscurely.
• Expiry is what the token asserts. A server that does not verify signatures would accept a forged token with any expiry at all, so "not expired" is not a statement about access.
• Decoding happens on your device, but a token you paste anywhere still ends up in your clipboard and your browser history. Treat a pasted production token as one to rotate.

Questions