How to use the JWT Decoder
- Paste the token, with or without the Bearer prefix. Decoding happens as you type.
- Read the header (algorithm and type), the payload (claims) and the colour-coded segments of the token.
- Check the expiry badge and the warnings: expired tokens, alg none and future not-before times are flagged.
- Copy the header or payload JSON if you need it elsewhere.
Features
- Decodes header and payload from Base64URL locally
- Translates exp, iat, nbf and auth_time into dates with relative time
- Explains registered claims such as iss, sub, aud and jti
- Warns about expired tokens, unsigned (alg: none) tokens and tokens not yet valid
- Recognises encrypted JWE tokens and explains why they can't be read
What a JWT contains
A JWT is three Base64URL-encoded parts separated by dots: a header that names the signing algorithm, a payload of claims about the subject, and a signature computed over the first two parts with a secret or private key. Because the header and payload are only encoded, not encrypted, anyone who has the token can read them; that's by design, and it's what this tool does.
Why decoding is not verification
Verification means recomputing the signature with the right key and comparing it to the token's signature. Without the key, a decoder can't tell a genuine token from one somebody typed by hand. Never grant access based on what a token says until your backend has verified it, and never paste production tokens into tools that send them to a server. This one doesn't.
Common claims
The registered claims defined by RFC 7519, all optional:
- iss (issuer) – who created the token; sub (subject) – who it is about; aud (audience) – who should accept it
- exp (expiration), nbf (not before) and iat (issued at) – Unix timestamps in seconds
- jti (JWT ID) – a unique id, useful for revocation lists