JWT Decoder
Paste a JSON Web Token to read its header and payload, with timestamps converted to readable dates and expiry checked. Everything happens locally — your token is never sent anywhere.
The three parts of a JWT
- Header — the signing algorithm and token type, e.g.
{"alg":"HS256","typ":"JWT"}. - Payload — the claims: who the token is about, who issued it, when it expires, and any custom data.
- Signature — a cryptographic signature over the first two parts, which proves the token has not been altered.
The payload is readable by anyone
This is the single most important thing to understand about JWTs. The header and payload are only Base64URL encoded, not encrypted — as this page demonstrates by decoding them without any key. Never put anything confidential in a JWT payload. No passwords, no personal data beyond an identifier, no internal secrets. Anyone who obtains the token, including the user it was issued to, can read every claim in it. The signature guarantees the token has not been modified; it does nothing to keep the contents private.
Standard claims
iss— issuer, who created the token.sub— subject, usually the user ID.aud— audience, who the token is intended for.exp— expiry, as a Unix timestamp. Decoded above into a readable date.nbf— not valid before this time.iat— issued at.jti— a unique token ID, used to support revocation.
This tool does not verify signatures
Decoding and verifying are different operations. Verification requires the secret or public key and must happen on your server — never in a browser, where any key you used would be exposed. A decoded token proves nothing about authenticity: an attacker can craft any payload they like and it will decode perfectly here. Always verify the signature server-side before trusting a single claim, and reject tokens whose alg is none.