JWT Decoder
Paste a JSON Web Token to see the header and the payload claims laid out as JSON, with iat, exp and nbf converted to dates so you can tell at a glance whether a token has expired.
100% private — everything runs in your browser, nothing is ever uploaded.
What this tool does
A login flow returns a long dot-separated token and you need to know whether it has expired, which issuer signed it, or what roles the payload contains. A JSON Web Token is three Base64 pieces: a header, a payload and a signature. This tool decodes the first two and lays the claims out as readable JSON, converting iat, exp and nbf from Unix seconds into dates so an expiry is obvious at a glance. It is aimed at debugging: checking why an API rejected a request, confirming an audience claim matches your service, or spotting that a token was issued for the wrong environment. It does not verify the signature, because verification requires the signing key and a server-side check. Never paste a production token into an online decoder you do not control; here the decoding stays in your tab.
How to use it in three steps
- Paste the complete token, including all three dot-separated parts. The header and payload appear as formatted JSON immediately.
- Read the header for the algorithm and key identifier, then the payload for subject, audience, issuer and any role or scope claims.
- Check the timestamps section for the human-readable issue and expiry times. That is usually enough to explain a 401 response without a server round trip. Compare the exp value with your own clock in UTC, since a local-time mismatch can make a valid token look expired.
Questions people ask
Does this verify that the token is genuine?
No. Decoding only reads the header and payload; verifying the signature needs the signing key and should happen on your server. A token that decodes cleanly can still be forged or expired.
Why is the expiry shown in a different hour than I expected?
The exp claim is a Unix timestamp in UTC, and this tool also shows local time so you can compare it with your own clock. A mismatch between the two is a common source of confusion when debugging across time zones.
Is it safe to paste a real access token here?
The token never leaves your browser on this site, but it is still a credential. Treat decoded claims as sensitive, avoid sharing screenshots containing them, and use a short-lived test token when you are only checking a claim's shape.
What if my token has only two parts or no signature at all?
A standard JWT has three dot-separated sections. Two parts usually means an unsecured or truncated token, which the tool will show as incomplete. A valid-looking header and payload still do not prove authenticity, because the signature is the part that carries that guarantee.
Privacy: The token is split and decoded by JavaScript inside this browser tab; its header, payload, claims and any embedded identifiers are never transmitted, logged or stored on any server.
How to use it
- Paste the token — the whole thing, including all three dot-separated parts.
- The header and payload are decoded and shown as formatted JSON.
- Check the timestamps section to see when the token expires.
Why it stays private
A JWT is a bearer credential: anyone holding it can act as the user it represents. Pasting one into a third-party decoder hands that credential to a stranger. This tool decodes locally, and the page is a single static file with no network calls.
Questions
Does this verify the signature?
No, and it deliberately does not try. Decoding is just Base64 and JSON parsing. Verifying a signature requires the signing key or public key, which is a server-side operation. Treat a decoded payload as a claim, not as proof.
Is it safe to paste a real token here?
The decoding happens in your browser and nothing is sent anywhere, so it is far safer than a hosted decoder. Even so, a JWT is a password. If a token has already been exposed, revoke it rather than trusting any tool with it.
Why does the expiry look wrong?
JWT timestamps are Unix seconds in UTC. They are shown here in ISO 8601 with an explicit timezone so there is no ambiguity. A common cause of confusion is a server that issued the token with a clock that was itself out of sync.
What is actually inside a JWT?
Three pieces joined by dots: a header naming the algorithm, a payload carrying the claims (who you are, what you may do, when it expires), and a signature proving the payload was issued by whoever holds the signing key. All three are merely Base64-encoded, not encrypted — paste any token anywhere and the payload is readable, which is exactly what this page shows you. The signature is what makes the token tamper-proof, not secret.
What is the difference between iat, exp and nbf?
All three are Unix seconds, and together they form the token's validity window. iat is when it was issued, exp is when it stops working, and nbf is a not-before gate used when a token should not work yet — for a link that goes live at midnight, for instance. A token is valid only between nbf (if present) and exp; an expired token should be refused no matter how intact its signature is.