JWT Decoder
Read a token's claims and expiry without sending the token anywhere.
A JWT is three Base64URL segments, not encryption
The structure is header.payload.signature. The header is a JSON object naming the signing algorithm and token type; the payload holds claims; the signature is a keyed MAC or a public-key signature over the first two segments joined by a dot. Every byte of the header and payload is readable by anyone who holds the token — Base64URL is not encryption.
Using a decoder on a live production token is a real risk: the token is the credential. Prefer doing this locally, as this page does, and never paste a production token into a site that transmits it.
The claims worth checking first
| Claim | Meaning | Failure mode if ignored |
|---|---|---|
alg | Signing algorithm | none or algorithm confusion lets an attacker forge tokens accepted by careless libraries |
exp | Expiry, Unix seconds | Long-lived access tokens that a stolen credential never retires |
nbf | Not before | Tokens used earlier than intended |
iat | Issued at | Age checks and clock-skew analysis become impossible |
aud | Audience | A token minted for another service is accepted here |
iss | Issuer | A token from an untrusted issuer is treated as your own |
The alg: none trap
Early JWT libraries accepted a token whose header declared "alg":"none" and skipped verification entirely — turning 'decode this token' into 'trust this token'. The mirror-image bug is algorithm confusion: an RS256 token is re-signed as HS256 using the public key, which the library then treats as an HMAC secret. Defences are simple and non-negotiable: pin the expected algorithm, verify the signature with a trusted key, then validate iss, aud, exp and nbf.
Where people get hurt by long expiry
exp is optional, and a token without it never expires by its own rules. A refresh token with a ten-year exp and no revocation list is effectively a permanent password. Check exp first, then confirm your server actually validates it rather than only the client.
How to use it
- Paste the token.
- Read the algorithm in the header and the claims in the payload.
- Check the expiry state shown below the timeline.
- Confirm your server pins the algorithm and validates issuer and audience.
Worth knowing
- Segments are Base64URL-encoded, so
-and_replace+and/, usually without padding. exp,iatandnbfare NumericDate values — seconds since the Unix epoch, not milliseconds.- JWE, the encrypted form, is a five-segment token and is genuinely confidential.
- The signature covers only the header and payload, never the HTTP request around them.
Limitations
- Decoding does not verify the signature — a token can be perfectly well formed and forged.
- This page does not pull the key from your JWKS endpoint; verification belongs on the server.
- A decoded claim is not a trusted claim until signature and audience checks pass.
- Never paste a live production token into a service that logs or transmits it.
Frequently asked questions
Does this verify the signature?
alg, iss, aud, exp and nbf can all be checked together.Is a JWT encrypted?
Why does my payload look like garbage?
- and _) while the decoder expects standard Base64 (+ and /), or the padding has been stripped. This tool handles both.