JWT Decoder
Inspect a JSON Web Token's header, payload and expiry.
| Claim | Value |
|---|---|
| subSubject | 1234567890 |
| name | Ada Lovelace |
| admin | true |
| iatIssued at | 1516239022 — 1/18/2018, 6:30:22 AM |
| expExpires at | 1767225600 — 1/1/2026, 5:00:00 AM |
The signature is not verified — that would require your secret or public key. Decoding proves nothing about authenticity, so never trust an unverified token in code.
About this tool
Paste a JWT to read its header and payload. Timestamp claims like iat, exp and nbf are rendered as human dates, and an expired token is flagged immediately so you are not left guessing why a request returned 401.
How to use it
- Paste the full token, including both dots.
- Read the decoded header and payload.
- Check the expiry badge to see whether the token is still valid.
What the three parts actually contain
A JWT is three Base64URL segments separated by dots: header.payload.signature.
Header names the signing algorithm and token type — typically {"alg":"HS256","typ":"JWT"}.
Payload holds the claims. Registered ones have defined meanings: iss (issuer), sub (subject, usually the user id), aud (audience), exp (expiry), nbf (not before), iat (issued at), jti (unique token id). Everything else is application-specific.
Signature is computed over the first two parts using a secret or private key. It proves the token has not been altered.
The critical point: the header and payload are encoded, not encrypted. Base64URL is trivially reversible — that is why this page can read your token without any key. Never put anything in a JWT payload that the holder should not see.
Why decoding is not verification
This tool deliberately stops at decoding. Verifying a signature would mean sending your secret or public key somewhere, which is exactly the thing you should never do.
That distinction matters in your own code too, and getting it wrong is a well-known vulnerability class:
The alg: none attack. Early JWT libraries honoured a header claiming no signature was used. An attacker edits the payload, sets alg to none, strips the signature, and the token is accepted. Always pin the expected algorithm server-side rather than trusting the header.
Algorithm confusion. If a server accepts both HMAC and RSA, an attacker can take the public RSA key — which is public — and use it as an HMAC secret. The server verifies successfully. Again: pin the algorithm.
Expiry is not automatic. exp is only enforced if your library checks it and you have not disabled that check. This tool shows you the expiry so you can confirm what you are holding.
Frequently asked questions
- Does this verify the signature?
- No, and deliberately so — verifying would mean sending your secret or public key somewhere. This tool only decodes. Never trust an unverified token in production code.
- Is it safe to paste a real token here?
- The decoding happens entirely in your browser and nothing is transmitted. That said, a JWT is a live credential until it expires, so treat it the way you would treat a password.
- Is it safe to paste a production token?
- The decoding happens entirely in your browser and nothing is transmitted. But a JWT is a live credential until it expires, so treat it as you would a password and avoid pasting one into any tool you have not verified.