Paste a JWT to see its decoded header and payload. Decoding only — this does not verify the signature.
A JWT (JSON Web Token) is a compact, three-part token used to carry claims — who a user is, what they're allowed to do, when the token expires — typically for authentication in REST APIs. This tool decodes the header and payload sections so you can read their contents directly, instead of eyeballing a wall of base64.
It decodes only — it does not and cannot verify the signature, since that requires the secret key or public key the token was signed with, which should never be pasted into a third-party tool.
A JWT is three base64url-encoded segments joined by dots: header.payload.signature. This tool splits on the dots, base64url-decodes the first two segments, and parses each as JSON — the same process any JWT library performs before checking the signature.
The signature segment is displayed but never decoded or verified, since it's a cryptographic hash, not JSON — verifying it correctly would require the signing key.
A decoded payload typically looks like:
No — it only decodes the readable parts. A token could be decoded perfectly here and still have an invalid signature. Never trust a JWT's contents without verifying its signature server-side with the correct key.
Decoding happens entirely in your browser and the token is never sent anywhere — but as a general habit, avoid pasting tokens from production systems into any third-party tool, including this one.
"iat" (issued at) and "exp" (expiration) are standard JWT claims storing Unix timestamps — this tool converts exp into a readable date and flags whether it has passed.
The header identifies the signing algorithm (like HS256 or RS256) and token type (JWT) — it's intentionally minimal; the actual claims live in the payload.
Yes — any valid base64url-encoded JSON payload decodes correctly, standard claims or not.