JWT Decoder (header, payload, signature, expiry)

What a JWT looks like

A JWT is three Base64url-encoded segments joined by dots: header.payload.signature. Each segment is a JSON object encoded for URL-safe transmission. The header declares the signing algorithm, the payload carries claims (subject, expiry, custom data), and the signature lets the recipient verify integrity if they have the key.

This decoder reads only the first two segments. The signature is the third segment but verifying it requires the secret/public key — that's a separate operation we don't perform here.

Standard claims worth knowing

iss (issuer): who created the token. iat (issued at): when, as Unix timestamp. exp (expiry): when it stops being valid, also Unix. nbf (not before): the earliest time it should be honored. sub (subject): the entity it represents, often a user ID. aud (audience): who the token is for, usually a service URL.

Not all are mandatory; minimal JWTs often have just sub + iat + exp. Custom claims are anything else — they live alongside the standard ones in the payload.

Why decoding ≠ verifying

Anyone can decode a JWT — the header and payload are just Base64-encoded JSON. That's why we say 'never put secrets in the payload': they're effectively public.

Verification means checking the signature against the secret key (HMAC) or public key (RSA/ECDSA). Without verification, you can't trust any claim inside the payload — an attacker can craft any payload they want.

Use this tool to inspect tokens during debugging. Use a JWT library on your server to verify them in production.