JWT Debugger & Decoder
Decode and inspect JSON Web Tokens instantly. See the header, payload, and signature — all parsed and readable. Your tokens never leave your browser.
🔍 Instant decoding
Paste any JWT and see the header, payload, and signature decoded and formatted immediately — no button press needed.
⏱ Expiry detection
The exp, iat, and nbf claims are automatically parsed into human-readable dates with live expiry status.
🔒 100% private
Your tokens never leave your browser. No server, no logs, no third parties. Safe to use with real production tokens.
🎨 Color-coded parts
Header, payload, and signature use both section labels and color cues — blue, purple, and green — matching the industry standard used by jwt.io.
⚡ Algorithm detection
Automatically reads the alg field and tells you exactly which signing algorithm was used.
📋 Claims inspector
Standard JWT claims like sub, iss, and aud are explained in plain English with their current values.
How to use the JWT Debugger
How JWT verification works
When your server receives a JWT, it splits it into header, payload, and signature. It then recomputes the signature using the header, payload, and the signing key. If the computed signature matches the signature in the token, the token is valid and has not been tampered with. If they don't match, the token is rejected. For RS256 tokens, the server only needs the public key to verify — the private key that created the signature never needs to leave the auth server.
Decoding a JWT without a library
The header and payload are just Base64url-encoded JSON. You can decode them in any language without a JWT library: split on ".", Base64url-decode each part, and parse as JSON. The signature requires the key to verify, but the claims are always readable without it. This is why you should never put sensitive data in a JWT payload — anyone who obtains the token can read the claims.
JWT expiry and the exp claim
The exp claim is a Unix timestamp (seconds since January 1, 1970). A token with exp: 1711126800 expires at that timestamp regardless of when it was issued. Always check expiry before trusting a token. Short-lived access tokens (15 minutes to 1 hour) paired with longer-lived refresh tokens (days to weeks) is the recommended pattern for web applications.
Common JWT debugging scenarios
Token expired: check the exp claim against the current Unix timestamp. Wrong algorithm: compare the alg in the header against what your server expects. Missing claims: check the payload for required fields like sub, iss, and aud. Signature invalid: the token was tampered with, the wrong key is being used for verification, or the signing key rotated. Paste the token into the debugger to inspect all claims instantly.