What's Inside a JWT? Decoding Tokens Safely
2026-06-03 · 5 min read
A JWT is not encrypted — anyone can read it. Here is what the three parts contain and why that matters for security.
JSON Web Tokens (JWTs) are everywhere in modern authentication. They look like an opaque string of gibberish, but they are actually three Base64URL-encoded sections that anyone can decode — a fact with important security implications.
The three parts
- Header — the token type and signing algorithm (e.g. HS256).
- Payload — the claims: who the user is, when the token expires, and any custom data.
- Signature — a cryptographic seal that proves the token was not tampered with.
Encoded, not encrypted
The header and payload are merely Base64-encoded, not encrypted. Anyone holding the token can read its contents. Never put secrets — passwords, card numbers, private data — in a JWT payload.
Common claims
Standard claims include sub (subject/user ID), exp (expiry timestamp), iat (issued-at), and iss (issuer). The exp claim is a Unix timestamp, so a token is expired once the current time passes it.
The signature is what provides trust. Decoding a token is safe and easy, but only the server with the secret key can verify it. Never trust a token's claims without verifying the signature server-side.
Inspect a token
The JWT Decoder splits any token into its header, payload, and signature, shows the claims, and flags whether it has expired — all in your browser.