A JSON Web Token (JWT) looks like a long random string, but most of it is just Base64-encoded JSON you can read. When you are debugging auth, being able to see what is inside saves a lot of time. Here is how.
The three parts
A JWT has three sections separated by dots: header.payload.signature.
- Header: the algorithm and token type, for example
{"alg":"HS256","typ":"JWT"}. - Payload: the claims, such as the user id (
sub), issued-at time (iat), and expiry (exp). - Signature: a cryptographic check that the token was not tampered with.
The header and payload are only Base64-encoded, not encrypted. Anyone can read them.
Decode one in two steps
- Open the JWT Decoder.
- Paste the token. The header and payload are shown as readable JSON instantly.
It runs in your browser, so the token never leaves your device, which matters because a JWT often grants access to an account.
Decoding is not verifying
This is the key point. Reading a JWT tells you what it claims, not whether those claims are true. Only the server, using the secret or public key, can verify the signature. Never trust a JWT’s contents on the client as proof of anything. Decode it to debug; verify it on the server to authorize.
Check the expiry
The most common JWT bug is an expired token. Look at the exp claim, which is a Unix timestamp. If it is in the past, the token is dead and the server should reject it. The decoder shows these times so you can spot it quickly.
Related tools
- The
expandiatclaims are Unix timestamps; convert them with the Unix Timestamp Converter. - Need to decode the Base64 yourself? Use Base64 Encode / Decode.
- Inspecting the payload JSON? Try the JSON Formatter.
Paste, read the claims, check the expiry. Just remember: decoding shows you the token, the server is what trusts it.