How to Decode a JWT: Reading JSON Web Tokens Safely
Log into almost any modern web app and a JSON Web Token — a JWT, often pronounced 'jot' — is probably working behind the scenes to keep you signed in. It looks like an intimidating wall of random characters, but a JWT is actually a structured, readable object once you know how it is put together. Being able to decode one is an everyday skill for anyone building or debugging web applications.
The three parts of a JWT
A JWT is three Base64URL-encoded sections joined by dots: header.payload.signature. The header says which algorithm signed the token. The payload (also called the 'claims') carries the actual data — who the user is, when the token expires, and any other information the app stored. The signature is a cryptographic seal that lets the server confirm the token has not been tampered with. The two dots make the three parts easy to spot.
How decoding works
Decoding a JWT means Base64URL-decoding the header and payload back into readable JSON. Because Base64 is just an encoding, not encryption, anyone can do this — no secret key is required. That is an important security point: the contents of a standard JWT are not hidden, merely encoded. You should never put passwords or sensitive secrets in a JWT payload, because anyone holding the token can read them in seconds.
Decoding is not the same as verifying
This is the distinction that trips people up. Decoding reveals what a token claims. Verifying proves those claims are genuine. The signature is what makes verification possible: the server recomputes it using a secret key and checks it matches. If someone edits the payload — say, changing their role to 'admin' — the signature no longer matches and a properly built server rejects the token. So you can read any JWT, but only the server with the key can trust it.
- Header: the signing algorithm and token type.
- Payload: the claims — user ID, expiry time, issued-at time, and custom data.
- Signature: the cryptographic proof that the header and payload were not altered.
- Decoding reads the first two; verifying checks the third.
Common claims you will see
Most JWT payloads share a handful of standard fields with short, cryptic names. 'sub' (subject) identifies the user the token is about. 'exp' (expiry) is a timestamp after which the token is no longer valid, and 'iat' (issued-at) records when it was created. 'iss' (issuer) names who created the token. These timestamps are written in seconds since 1970, which is why a decoder that converts them to a human-readable date is so handy when you are checking whether a token has expired.
Frequently asked questions
Is the data in a JWT encrypted?
No. A standard JWT is encoded, not encrypted, so anyone with the token can read the header and payload. There is a separate encrypted variant, but ordinary JWTs simply rely on the signature to prevent tampering, not to hide the contents.
Why can't I just edit the payload?
You can edit it, but the change breaks the signature. A correctly configured server recomputes the signature with its secret key, sees the mismatch, and rejects the altered token — so tampering is detected even though reading is possible.
Is it safe to paste a token into an online decoder?
Be cautious with real tokens. A token is a live credential while it is valid, so prefer a decoder that runs in your browser without sending the token anywhere, and never paste production tokens into tools you do not trust.
The bottom line
A JWT is just three Base64URL-encoded parts — header, payload and signature — carrying readable claims sealed by a cryptographic signature. Decoding shows you what a token says; only the signing key can prove it is genuine. Keep secrets out of the payload, mind the expiry, and handle real tokens carefully. Our JWT decoder breaks any token into its parts and decodes the timestamps for you in one click.