JWT Decoder
Free JWT decoder. Paste any JSON Web Token to view its header, payload, and signature. Decodes Base64 client-side — your tokens never leave the browser.
Quick answer
A JSON Web Token has three Base64URL-encoded parts separated by dots: header (algorithm, type), payload (claims like sub, exp, iat), and signature. Decoding reveals the contents but doesn't verify the signature — anyone can read a JWT, only the issuer can sign one.
JWT Decoder (Header / Payload)
How it works
JSON Web Tokens have three parts separated by dots: a Base64URL-encoded header, payload, and signature. This tool decodes the header and payload but does NOT verify the signature — verification requires the secret key, which should never be sent to a third party.
When to use it
Inspecting token contents during development, checking expiration times, debugging authentication flows, or seeing what claims an OAuth provider is sending you.
Common mistakes
Treating decoded payload data as trusted. Anyone can read a JWT — only the signature provides authenticity. Never put secrets in a JWT payload, only public claims.
How the JWT decoder works
The tool splits the JWT on its two dots into header, payload, and signature. The header and payload are Base64URL-encoded JSON — the decoder Base64-decodes each and pretty-prints the resulting JSON. The signature is shown as the raw Base64URL string; verifying it requires the issuer's secret or public key, which the tool intentionally doesn't accept. All processing happens client-side, so your tokens never leave the browser.
When to use it
Debugging authentication flows where you need to see what claims the API is sending. Inspecting expired vs. fresh tokens (decode and check the 'exp' claim). Confirming a JWT is properly formatted before troubleshooting downstream issues. Reading token payloads from network captures or debug logs.
Common mistakes
- Treating decoding as verification. Anyone can decode a JWT — including an attacker. Verification requires checking the signature against the issuer's secret/key. The decoder shows you the contents; it does not validate authenticity.
- Putting secrets in the payload. JWT payloads are plain Base64 — anyone with the token can read them. Never put passwords, tokens, or PII in the payload unless the channel is also encrypted.
- Ignoring the 'alg' field. Some libraries accept 'alg: none' tokens (unsigned), which is a serious security flaw. Always reject unexpected algorithms in your verification code.
Frequently asked questions
Is decoding a JWT the same as verifying it?
No. Decoding just Base64-decodes the contents — anyone with the token can do this. Verifying checks that the signature matches the payload using the issuer's secret or public key. The decoder here does not verify; it only shows the contents.
Can I read the payload of any JWT?
Yes. JWT payloads are Base64URL-encoded JSON — they're trivially decodable. This is why you should never put sensitive data (passwords, tokens, PII) in a JWT payload. If confidentiality matters, encrypt the payload (JWE) or use opaque tokens instead.
How do I know when a JWT expires?
Check the 'exp' claim in the payload. It's a Unix timestamp (seconds since epoch). The decoder above converts it to a human-readable date. JWTs without an 'exp' claim never expire — usually a misconfiguration.