JWT Decoder

Anatomy of a JWT

A JWT is three base64url-encoded segments separated by dots: header.payload.signature. The header declares the signing algorithm. The payload contains claims — statements about the subject, often including sub (who), iat (issued at), exp (expires at), and custom application data. The signature is a cryptographic verification of the first two parts, produced by the issuer using a secret or private key.

What this decoder does and does not do

• It does: decode the header and payload so you can read them, and flag expired tokens.
• It does not: verify the signature. Signature verification requires the issuer's secret or public key, which this tool does not have and should not have. Anyone can decode a JWT, but only the issuer can prove it is authentic.
• The takeaway: never trust a JWT's contents on the client side without verifying the signature on your server.

Common claims decoded

• iss — issuer (who created this token).
• sub — subject (who the token refers to, usually a user ID).
• aud — audience (who the token is intended for).
• iat — issued at (Unix timestamp).
• exp — expires at (Unix timestamp). Tokens past this are invalid.
• nbf — not before (Unix timestamp). Tokens before this are invalid.
• jti — JWT ID (unique token identifier, used for revocation).

Security tips

Never paste a JWT from a production system into any online tool whose trust you have not verified. This tool runs entirely in your browser — nothing is uploaded — but the habit of pasting secrets into random websites is dangerous because most tools do not make that guarantee. Verify by checking the network tab: generating output should produce zero network requests.