TontonTools

JWT Token Decoder

Decode JWT tokens — read the header and payload instantly.

100% Free No signup Privacy-friendly Password & Security
Updated Sep 2026

Decoding only — the signature is not verified. Never paste production secrets.

Share X / Twitter Facebook LinkedIn WhatsApp

How to use JWT Token Decoder

  1. Paste the JWT — the header.payload.signature string.
  2. Read the decoded header and payload — algorithm, claims, timestamps.
  3. Check exp first when debugging auth — expired tokens are the top cause of 401s.
  4. Remember: decoding ≠ verifying — your server must always validate the signature before trusting claims.

What is JWT Token Decoder?

A JWT decoder unpacks a JSON Web Token — the dot-separated header.payload.signature string that carries authentication and session data across the modern web — into readable JSON. It decodes the Base64URL header (algorithm, type) and payload (the claims: user ID, roles, expiry, issuer) so you can see exactly what a token asserts.

The critical thing to understand: a JWT is encoded, not encrypted. Anyone can decode and read the payload — it's Base64, not a secret. The signature doesn't hide the data; it proves the data wasn't tampered with. So JWTs must never carry secrets, and decoding one reveals everything it holds.

About the JWT Token Decoder

Paste a JWT and read its decoded header and payload — claims laid out, expiry and timestamps interpreted — all in your browser.

Where it earns its place: debugging authentication — the daily use: an API returns 401, and decoding the token shows whether it's expired (the exp claim vs now — the #1 cause), missing a role, or issued for the wrong audience; inspecting claims — confirming a token carries the user ID, permissions and scopes your app expects; reading expiryexp, iat and nbf as human dates, diagnosing "logged out too soon" and clock-skew issues; and learning how JWT auth works — seeing real tokens demystifies the whole flow.

Security essentials this reinforces: decoding does NOT verify — a valid-looking decoded payload could be forged; only checking the signature against the secret/public key (server-side) proves authenticity, and your app must always do that. Never trust a JWT's claims without verifying its signature. And since decoding exposes the payload, treat production tokens like the credentials they are — this decoder runs entirely client-side, so nothing you paste is transmitted. See HMAC (which produces HS256 signatures) for the signing side.

Frequently Asked Questions

No — encoded (Base64URL), not encrypted. Anyone can decode and read the payload. The signature proves integrity (not-tampered), not confidentiality. Never put secrets in a JWT — assume its contents are public.
Most often expiry — decode it and compare the exp claim to now (the top cause of sudden 401s). Other suspects: wrong audience/issuer, missing scopes, clock skew between servers, or a signature that fails verification.
No — decoding just reads the Base64. Verification means checking the signature against the secret (HS256) or public key (RS256), which only the server can do securely. A decoded payload could be entirely forged; never trust claims without signature verification.
exp (expiry), iat (issued-at), nbf (not-before), iss (issuer), aud (audience), sub (subject/user), jti (token ID). Plus any custom claims your app adds (roles, permissions). The decoder shows them all.
Decoding runs entirely in your browser — nothing is sent. But treat production tokens as live credentials regardless: they grant access until they expire, so avoid pasting them into any server-side tool, and don't leave them in shared logs.

We use cookies for analytics and to keep the tools free via ads. See our Privacy Policy.