10 min read · Try JWT Decoder
Three parts, two jobs
A JSON Web Token has a header (algorithm and type), a payload (claims), and a signature. Decoding the payload is trivial Base64url—it tells you what the issuer asserted. Trusting those assertions requires cryptographic verification with the correct key and validation of time-bound claims.
Claims you should always check server-side
exp (expiration) and nbf (not before) bound the token’s lifetime. aud (audience) and iss (issuer) prevent tokens minted for one API from being replayed on another. If you use scopes or custom permissions, enforce them in authorization logic, not only in the UI.
- Clock skew: allow a small leeway (for example 30–60 seconds) when comparing exp to server time.
- Reject alg=none and unexpected algorithms unless you explicitly support them.
What developers use decoders for
During integration, paste a token from staging to confirm the identity provider included the roles you expected. Compare iat and exp to explain “session expired” tickets. Never treat a decoded payload as proof of identity in your own backend without signature verification.
Operational hygiene
Rotate signing keys on a schedule. Log token IDs (jti) rather than full bearer strings. Short-lived access tokens plus refresh flows limit damage when a token leaks.
This article is part of the DevToolsHub learning guides—original writing meant to complement our free tools, not replace official documentation from vendors or standards bodies.