JWT / Token Decoder Guide
Use this guide to decode JWTs for troubleshooting, inspect risky algorithms and expiry claims, and keep token handling safe.
Overview
JSON Web Tokens contain a header, payload, and signature. Decoding reveals claims such as iss, aud, exp, and sub, but signature verification must always happen on the server.
What to inspect
- Algorithm: Reject tokens using none or unexpected signing algorithms.
- Expiry: Review exp and nbf to confirm the token lifetime matches policy.
- Audience and issuer: Validate aud and iss before trusting authorization decisions.
Important JWT claims
| Claim | Meaning | Review focus |
|---|---|---|
| alg | Signing algorithm | Must not be none in production |
| exp | Expiration time | Should be short-lived for access tokens |
| aud | Audience | Must match the intended service |
| iss | Issuer | Must match your trusted identity provider |
Safe inspection workflow
Debug an API token
Decode the JWT locally, inspect alg/exp/aud/iss, then verify the signature on the server with the correct secret or JWKS key.Recommended Remediation Flow
- Verify server-side Never trust decoded payload data until the signature is validated.
- Reject risky algorithms Block none and unexpected alg values at verification time.
- Treat tokens as secrets Do not paste production tokens into third-party websites.
Troubleshooting Common Issues
Decoded payload looks valid but API rejects token
The signature or claim set may still be invalid.
- Check clock skew against exp and nbf.
- Confirm aud and iss match server expectations.
- Verify the signing key or JWKS endpoint.
Validation Checklist
Post-fix validation
- Signature verification happens on the server.
- none is rejected.
- Token lifetimes and audiences match policy.
FAQ
Can I trust a decoded JWT?
Not by itself.
- Decoding is not verification.
- Anyone can craft a Base64 payload.
- Only signature validation proves integrity.