JWT Decoding Explained: How to Read a JSON Web Token Safely
Understand JSON Web Tokens (JWT): structure, header, payload, signature, and how to decode one safely in your browser — plus why you should never trust an unverified token.
JSON Web Tokens (JWTs) are everywhere in modern authentication — APIs, single sign-on, session tokens. They look like a random string of gibberish, but they're actually structured and easy to read once you know the format. This guide explains what's inside a JWT and how to decode one safely.
The three parts of a JWT
A JWT is three Base64URL-encoded sections joined by dots: header.payload.signature. The dots make it easy to spot. Each part has a distinct job.
1. Header
Describes the token: the type (JWT) and the signing algorithm (e.g. HS256 or RS256). It tells a verifier how the signature was produced.
2. Payload
Contains the 'claims' — the actual data, such as the user ID (sub), issuer (iss), audience (aud), and expiry (exp). This is usually what you care about when debugging.
3. Signature
A cryptographic signature over the header and payload, created with a secret or private key. It lets a server verify the token wasn't tampered with — but verifying it requires the key.
Decoding is not the same as verifying
Decoding a JWT only reads the header and payload. It does NOT prove the token is valid. Anyone can read a JWT's contents — only the server with the key can verify its signature.
This is the single most important thing to understand about JWTs. The payload is merely Base64-encoded, not encrypted — so never put secrets in it, and never trust a token's claims without verifying the signature server-side.
Decode safely: do it client-side
Because a JWT can contain identifying or sensitive claims, you should decode tokens in a tool that runs entirely in your browser and never transmits the token to a server. Our JWT decoder does exactly that — the token never leaves your device.
Common things to check when debugging
- exp (expiry) — has the token expired?
- iat (issued at) — when was it created?
- iss / aud — does the issuer and audience match what you expect?
- alg in the header — is it the algorithm your backend requires?
- sub — which user or subject does the token represent?
Once you can read the three parts, JWTs stop being mysterious. Just remember: read freely, but verify the signature on the server before trusting anything inside.