Decode any JSON Web Token to inspect its header, claims, and expiry — entirely in your browser.
Paste a token above to decode its header, claims, and expiry
A JSON Web Token (JWT, pronounced “jot”) is a compact, URL-safe way of representing claims between two parties, standardised in RFC 7519. Tokens are almost always used as bearer credentials: whoever holds the token is treated as the identity it asserts, so a leaked token is as good as a leaked password until it expires.
Every JWT is three base64url-encoded parts separated by dots — header.payload.signature. The header names the signing algorithm, the payload carries the claims, and the signature is what lets a server confirm nobody edited the first two parts.
The critical thing to internalise: the payload is encoded, not encrypted. Base64url is a transport encoding, not a cipher. Anyone holding a token can read every claim in it — which is exactly what this tool does, and exactly why sensitive data should never be placed in a JWT.
This is the distinction that causes real security incidents. Decoding is base64url decoding plus JSON.parse — about four lines of code, and it will happily “decode” a token you invented in a text editor. Verifying means recomputing the signature over the header and payload with the correct key and confirming it matches. Only verification proves anything.
A decoder that displayed claims without that distinction would be actively dangerous, because it invites you to trust a payload that has never been authenticated. This tool shows you the signature bytes and says plainly that it has not checked them — your server is the only component that can.
The classic attack this enables is the algorithm confusion family. In the alg: none variant, an attacker takes a legitimate token, edits the payload to escalate privileges, and rewrites the header to declare no signature — then sends it to a server that trusts the token’s own declaration of its algorithm. If that server does not reject none outright, the forged payload is accepted.
RFC 7519 defines seven registered claim names. They are not mandatory, but using them means every JWT library understands your token without custom handling.
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | The party that created and signed the token |
| sub | Subject | The identity the token asserts — usually a user ID |
| aud | Audience | The party the token is intended for; a token minted for one service should be rejected by another |
| exp | Expiration Time | After this time the token must be rejected |
| nbf | Not Before | Before this time the token must be rejected |
| iat | Issued At | When the token was created — informational, not enforced |
| jti | JWT ID | A unique identifier for this token, used for revocation lists and replay detection |
A common gotcha: iat alone does not expire a token. It records when the token was made so you can reason about its age — but a server that checks only iat and never exp will accept that token forever. When you decode a token with an iat but no exp, that is worth investigating.
Pin the algorithm. Never let the token declare which algorithm to verify with — the server decides. If your application uses HS256, verify with HS256 and reject everything else, including none.
Check the audience and issuer. A signature proves a token came from someone holding the key — not that it was minted for your service. If the same key signs tokens for several applications, skipping the aud check lets a token from a low-value service be replayed against a high-value one.
Keep expirations short and revoke actively. A JWT cannot be un-issued; a revocation list keyed on jti is what lets you kill a session before its exp arrives. That is exactly the pattern this site uses — sessions carry a version claim that is reconciled against the database on every request, so a password change immediately invalidates tokens that are still cryptographically valid.
Never put secrets in the payload. Anyone who sees the token can read every claim. No passwords, no internal hostnames, no personal data that would be a problem in a log file or a browser history.
DMC IT Services provides application security reviews, authentication design, and identity hardening for SMBs across London, Cambridge, Hertfordshire, and Bedfordshire.
Talk to an Engineer