JWT Decoder
Read the header and claims inside a JSON Web Token, with the timestamps in plain English.
Decoding only. The signature is not and cannot be verified here, because that needs a key that should never be pasted into a web page. Nothing you paste is transmitted.
How it works
A JSON Web Token is three Base64url segments joined by dots: a header saying how it was signed, a payload of claims, and a signature over the first two. The first two are <em>encoded, not encrypted</em>. Anyone holding the token can read every claim in it, which is worth saying plainly because tokens are routinely issued with more inside them than the issuer intended to publish.
Decoding is therefore trivial and happens entirely in this page. What cannot happen here is verification: checking the signature requires the secret or the issuer's public key, and a decoder that asked you to paste your signing secret into a web page would be asking for the one thing that must never leave your server.
So treat what you see below as *claims*, not *facts*. An unverified token proves nothing — anyone can craft one with `admin: true` in it. The signature is the only thing that makes a claim trustworthy, and it must be checked server-side, by a library, against a key you control.
The timestamps are where the practical bugs live. `exp`, `iat` and `nbf` are seconds since the Unix epoch, not milliseconds, and passing a JavaScript `Date.now()` straight into `exp` produces a token that expires roughly fifty thousand years from now. Getting it the other way round produces one that expired in 1970. Both are common, and both are shown here in readable form so they are obvious at a glance.
The `alg` field in the header deserves suspicion too. A token arriving with `alg: none` is asserting it needs no signature at all, and any verifier that honours that is trivially bypassed. Real libraries require you to state which algorithm you expect rather than trusting what the token claims about itself.
Common questions
Can you check whether the token is valid?
No, and deliberately not. Verifying a signature needs the shared secret or the issuer's public key. Any site that asks you to paste your signing secret is asking for the credential that lets it mint tokens as you. Verify server-side with a real library.
Is it safe to paste a token here?
The decoding is done in your browser and nothing is transmitted. That said, a live access token is a credential — treat pasting one anywhere with the same care you would a password, and prefer an expired or test token when you are only inspecting the shape.
Why does my expiry show a date in the far future?
You almost certainly wrote milliseconds where seconds were expected. JWT timestamps are seconds since 1970; JavaScript's Date.now() returns milliseconds. Divide by 1000.
The payload has personal data in it. Is that a problem?
It is visible to anyone holding the token, so yes, if it is anything you would not put in a URL. Tokens are frequently stored in browser storage and sent with every request. Keep them to identifiers and let the server look up the rest.