JWT Decoder for Claim and Expiry Checks
Inspect bearer tokens faster by decoding the header and payload, surfacing exp and iat, and focusing on the claims that usually break auth.
This guide is for debugging real auth failures. Decode the token, read the claims, and stay precise about what the tool can and cannot prove.
Use this when
An API rejects a bearer token and you need to inspect the header, claims, or timestamps before you retry.
What to inspect first
Check alg, exp, aud, scope, and sub first because they usually explain why a valid-looking token still fails.
Common pitfall
Decoding shows what the token says. It does not prove the signature is valid or trusted.
Paste only the raw token
If you copied an Authorization header, remove the Bearer prefix before you paste it into the decoder.
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Spot an expired token
Focus on exp first when the auth failure looks intermittent or environment-specific.
{"sub":"user-123","exp":1712732400}
Inspect custom claims
aud, scope, and sub often explain authorization mismatches even when the token shape looks fine.
{"aud":"api://comutil","scope":"read:users write:users","sub":"user-123"}
Check the segment structure
JWTs are three Base64URL segments, so malformed punctuation or padding can break a copied token.
header.payload.signature
Look at exp and iat for clock drift, aud for audience mismatches, and scope for missing permissions. Those checks are usually faster than reproducing the request again.
- Use the Unix Timestamp tool when exp or iat values are hard to read quickly.
This page reads the token structure and claim contents. It does not verify the signature, validate trust chains, or confirm that the token was issued by the expected signer.
- Stay precise in incident notes: decoded content is useful evidence, but it is not the same as verification.