2026-05-31 · 2 min read
How to decode JWT safely
Inspect tokens locally first; verify signatures only on the server.
Key takeaways
- Decoding shows structure, not trust—signature verification belongs on the server.
- Always check exp/iss/aud before using claims in business logic.
Recommended workflow
Paste the token into JWT Decoder to read header and payload fields.
Confirm exp is in the future for your clock skew tolerance, and that iss/aud match your issuer configuration.
In your backend, verify the signature with the correct key material and algorithms—never rely on browser decoding alone.
Limits of client-side tools
Browser-side decoding is for debugging and education. Treat it as read-only inspection, not authorization.
If a token is leaked, assume compromise: rotate keys and invalidate sessions according to your threat model.
Clock skew and the exp claim
Most identity providers mint exp as Unix seconds. If your laptop clock is two minutes fast, a token can look expired in JWT Decoder even though the API still accepts it within leeway.
Copy the exp integer into Timestamp Converter and compare UTC vs the issuer’s documented leeway (commonly 30–120 seconds) before filing an auth bug.
Never paste a production refresh token into a shared screen; use a sandbox client_id and redact sub/email claims in screenshots.
FAQ
Does decoding prove the token is valid?
No. Anyone can base64-decode JWT parts; validity requires cryptographic verification.
Should I paste production tokens here?
Avoid secrets in shared screens. Prefer test tokens or redact sensitive claims.
Does decoding HS256 vs RS256 change the payload?
No. Header and payload are Base64URL. The alg field only tells the verifier which key to use; this page never verifies signatures.