JWT Decoder

A JWT is three base64url-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm (alg) and usually a key identifier (kid). The payload carries the claims. The signature covers the first two segments exactly as they appear in the token.

Everything before the signature is encoded, not encrypted. Anyone holding the token can read the payload — including in a browser devtools panel or a server log. Never put anything in a JWT that the bearer shouldn't see. If you need confidentiality rather than integrity, you want JWE, not JWS.

This is the distinction that causes production incidents. Decoding parses the base64url and shows you the claims. Verifying checks the signature against a key, and confirms the token hasn't been altered and came from the issuer you expect.

A decoded-but-unverified token is attacker-controlled input. Anyone can craft a JWT with sub: "admin" and any claims they like. If your code reads claims without checking the signature, it will believe them. Always verify before you trust a single field.

iss — who issued it. Must match the issuer you configured, exactly. aud — who it's for. If it doesn't name your application or API, the token was minted for someone else and you should reject it.

exp and nbf — the validity window, as Unix timestamps in seconds (not milliseconds, a common off-by-1000 bug). iat — when it was issued, useful for enforcing a maximum age independent of exp. sub — the subject, which is the stable user identifier you should key off rather than an email address.