JWT Decoder
Decode a JSON Web Token to see its header and claims. Timestamps are rendered as readable dates with a relative offset, expiry is checked against your clock, and unsigned alg: none tokens are flagged. The signature is not verified — that needs the signing key, which you should never paste into a web page.
How to decode a JWT
- Paste the token. A leading
Beareris stripped automatically, and whitespace or line wrapping is ignored. - The header and payload are base64url-decoded and pretty-printed, with non-ASCII claims decoded as UTF-8.
- Registered claims —
iss,sub,aud,iat,nbf,exp— are broken out, with timestamps shown as dates plus a relative offset. - Check the status line for expiry and algorithm warnings.
- Switch Output to JSON if you want the decoded parts as data rather than a report.
Decoding is not verifying
A JWT has three parts: header, payload, signature. The first two are only base64url-encoded — not encrypted. Anyone holding the token can read every claim in it, which is why you should never put secrets in a JWT payload.
The signature is what makes a token trustworthy, and checking it requires the secret or public key. This tool deliberately does not verify: pasting a signing secret into any web page is a bad habit, even one that runs locally. Verify on your server, with a library, using a key from your key store.
So treat a decoded payload as claims someone made, not facts. An attacker can decode a token, change the payload, and re-encode it — the signature is the only thing that catches that.
What the warnings mean
- EXPIRED —
expis in the past according to your machine's clock. If that surprises you, check for clock skew before assuming the token is at fault. - NOT YET VALID —
nbfis in the future. Same caveat about skew; most verifiers allow a small leeway. - alg is "none" — the token is unsigned. This was the basis of a well-known family of authentication bypasses: a server that honours the header's algorithm choice can be told not to check the signature at all. A verifier must pin the expected algorithm rather than trust the header.
- No exp claim — the token never expires on its own. Whether that is a problem depends on whether you have a revocation mechanism.
Privacy
Nothing is uploaded. Decoding happens in this tab with your browser's own base64 and UTF-8 support. No token is transmitted, logged, or stored — which is the point, since a JWT is usually a live credential. Clear the pane when you are done anyway.
FAQ
Can you verify the signature if I paste the secret?
No, and that is on purpose. Verification belongs in your application, where the key lives in a key store rather than a text field. A tool that invites you to paste signing secrets into a browser is teaching a habit that will eventually cost someone a breach.
Why does it say my token has two parts?
An unsigned JWT is written with a trailing dot and an empty signature (header.payload.). If yours has no third segment at all it is malformed, or it is a JWE — encrypted rather than signed — which cannot be decoded without a key.
Is a JWT the same as a session cookie?
Different trade-offs. A session cookie is an opaque pointer to server-side state, easy to revoke. A JWT carries its claims in the token, so no lookup is needed but revoking one before it expires requires extra machinery — a deny-list or short lifetimes with refresh.
Does it work offline?
Yes, entirely. Useful when you are debugging an auth flow on a locked-down network.