What's Actually Inside a JWT: Decoding the Three Parts

A JWT looks like a random string: eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.lS4Vb... — three segments separated by dots. Paste it into a JWT decoder and it's suddenly readable English. That's the first thing most people learn and the first thing they misjudge. A JWT is not encrypted. It's signed.

The Three Parts

Every JWT has header, payload, and signature. The header declares the algorithm and token type. The payload carries the claims — who the token is for, when it expires, what it allows. Both are base64url-encoded, which is why they decode to plain text so easily; the base64 converter shows the same encoding trick on any data. The signature is the third part, and it's the one that actually does the security work.

Readable Doesn't Mean Safe

Because the payload is base64, anyone can read it. That's the point — the issuer wants the receiver to inspect the claims without a server round-trip. The consequence: never put secrets in a JWT payload. A password, an API key, or a personal detail in the payload is public the moment the token exists. The common mistake is assuming that because the token "looks encoded," it's protected. Encoding is not encryption.

What the Signature Actually Protects

The signature prevents tampering. The issuer computes a hash of the header and payload with a secret key, and the receiver recomputes it. Change one character in the payload and the signature stops matching — the token is rejected. It's the same one-way math behind the hash generator, but wrapped in a protocol: sign, don't encrypt. If a token needs its contents hidden, it needs real encryption, not a JWT.

Decoding a JWT tells you what's inside, not who vouched for it — that's what the signature is for. We walked through reading real tokens in our guide to debugging API tokens. Next time you see three dotted segments, decode them in the JWT decoder and read what the payload actually claims — then check whether the signature still checks out.