JWT Decoder

How to use JWT Decoder

1. Paste the token, or load the sample to see the structure.
2. Read the header to see the signing algorithm, and the payload for the claims.
3. Check the expiry status and the issued-at age.
4. To verify the signature rather than read the token, use your server’s library and key — not a web page.
5. Header and payload are Base64url encoded, not encrypted — treat everything in them as public.
6. exp, iat and nbf are Unix timestamps in seconds, not milliseconds; a token that looks like it expires in 1970 usually has milliseconds by mistake.
7. Decoding happens in your browser, but a production token pasted into any web page should be treated as worth revoking.

Three parts, two of them public

A JWT is three Base64url segments joined by dots. The header says which algorithm signed it. The payload carries the claims — who the token is about, who issued it, when it expires, and whatever else the issuer added. The signature is computed over the first two. Only the signature is protected: header and payload are encoded, not encrypted, so anybody holding the token can read them, as this page demonstrates in one paste. Never put a password, a card number or anything else confidential in a JWT payload.

The registered claims, and which ones matter

exp is the expiry as a Unix timestamp in seconds — the one this tool checks. iat is when it was issued, nbf the earliest time it is valid, sub the subject (usually a user id), iss the issuer, aud the intended audience and jti a unique token id used for revocation lists. A correct verifier checks exp, nbf, iss and aud, not just the signature: a perfectly signed token issued by the wrong party for a different audience is still a valid signature and an invalid token.

Decoding is not verifying

This tool tells you what a token says. It cannot tell you whether the token is genuine, because verification needs the secret or the public key, which only the server has. That distinction is the source of the most serious JWT vulnerabilities: libraries that decoded without verifying, and libraries that trusted the header’s alg field — letting an attacker set it to “none” and strip the signature, or switch an RS256 token to HS256 and sign it with the public key as the secret. Always verify against an algorithm your server chose, never the one the token claims.

What to do about an expired token

An expired access token is normal and expected — short lifetimes (5 to 15 minutes) limit the damage if one leaks, which is why they exist. The client exchanges a longer-lived refresh token for a new one. If you are debugging a 401, check exp here first: a clock skew of a few minutes between your machine and the issuer is a common and confusing cause, which is why most verifiers allow a small leeway.