What Is Actually Inside a JWT

A JWT is three chunks of Base64 separated by dots. That’s it. It looks encrypted and it isn’t — anyone holding the token can read everything in it, right now, without a key.

That single fact is the source of most JWT mistakes, so it’s worth being concrete about.

The three parts

Split on the dots and you get header, payload, signature.

The first two are Base64url-encoded JSON. Base64 is an encoding, not encryption. It exists so binary data survives a trip through something that only handles text. Decoding it needs no secret and takes microseconds.

What signing actually protects

The signature answers one question: has this token been modified since it was issued? Change a single character of the payload and the signature no longer matches.

It answers no other question. In particular it does not hide anything. If you put an email address, an internal user ID, a role name or a phone number in the payload, everyone who ever holds that token can read all of it.

Put nothing in a JWT payload that you wouldn’t put in a URL.

The claims worth knowing

Some claim names are standardised. These are the ones you’ll actually meet:

The three time claims are all Unix timestamps in seconds. Almost every JavaScript date API works in milliseconds. That mismatch is behind a good share of “my token expires immediately” and “my token never expires” bugs — see why your Unix timestamp is 1000× off.

Reading one safely

Debugging a token means pasting it somewhere. A production token is a live credential: whoever receives it can act as that user until it expires.

So the only safe place to paste one is a decoder that doesn’t transmit it. Our JWT Decoder runs entirely in the page — nothing is sent anywhere, and it deliberately stores nothing, not even locally, because a token is exactly the kind of thing that shouldn’t be sitting in your browser storage after you’ve finished.

It also flags the algorithm, which brings us to the interesting failure.

The alg: none problem

The header names the signing algorithm. Early libraries trusted it. So an attacker could take a valid token, change the payload to say they were an administrator, set "alg": "none", delete the signature, and send it. A library that read none and dutifully skipped verification let it straight through.

Modern libraries reject it, but the shape of the lesson survives: the server decides which algorithm is acceptable, not the token. A verifier that reads alg from the token and does what it’s told is trusting input it’s meant to be checking.

The related version swaps RS256 for HS256 — asymmetric for symmetric — so the library uses the public key as an HMAC secret. The public key is public. Same lesson.

Expiry is a rejection rule, not a delete button

A token past its exp doesn’t stop existing. It’s just supposed to be refused. That means:

• A stolen token works until it expires, which is why short lifetimes matter more than they feel like they should.
• There’s no built-in revocation. Logging out doesn’t invalidate a JWT unless you keep a deny-list, which is a piece of server state — the thing JWTs were meant to avoid.
• Clock skew between two servers can reject a valid token or accept an expired one. A few seconds of leeway is normal; a few minutes hides real problems.

The short version

Three Base64 chunks. The first two are public. The signature proves nothing was changed and hides nothing. Times are in seconds. Never trust the header’s algorithm claim, and never paste a live token into something that uploads it.