How to Read a JWT, and Why Decoding Is Not Verifying

A JSON Web Token looks like a long, opaque string, but it is mostly plain text in disguise. It carries who a user is and what they are allowed to do, and a server checks it on every request instead of looking the session up in a database. The catch that trips up newcomers is that reading a token and trusting a token are two completely different operations. Paste a token into the JWT Decoder to see its parts laid out, all in your browser.

Three parts, two dots

A JWT is three Base64url-encoded segments joined by dots: the header, the payload, and the signature. Split on the dots and decode the first two with Base64 and you get readable JSON. The third part is not JSON at all; it is the raw bytes of a cryptographic signature, which is why it looks like noise even after decoding.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjM0In0 . SflKxw...
     header (Base64url)                payload (Base64url)      signature

The header decodes to something like {"alg":"HS256","typ":"JWT"}: it names the signing algorithm and the token type. The payload holds the claims, the statements the token is making.

What lives in the payload

Claims are just JSON fields. Some are registered standard names with defined meanings; the rest are whatever the issuer chooses to add.

Decoding is not verifying

This is the heart of it. Decoding a JWT just Base64-decodes the header and payload so you can read them. It runs no checks. It does not tell you whether the token is genuine, whether it has been tampered with, or whether it has expired. A decoder will happily show you a token that someone typed by hand.

Verifying is the step that matters on the server. It recomputes the signature over the header and payload using the signing key and checks that the result matches the signature in the token. With a symmetric algorithm such as HS256 the same secret signs and verifies; with an asymmetric one such as RS256 a private key signs and the matching public key verifies. If a single byte of the payload changes, the signature no longer matches and verification fails. Only after a successful verification, and a check that the exp claim is still in the future, should an application believe anything the token says.

Signed is not the same as encrypted

The common JWT you see in an Authorization header is a JWS, a signed token. The signature guarantees integrity and authenticity: it proves the claims were not altered and came from someone holding the key. It does nothing to hide them. There is a separate standard, JWE, that actually encrypts the payload, but it is far less common. So if you are reaching for a JWT to keep data secret, you have the wrong tool; you want encryption, with the JWT carrying only a reference.

Two classic security mistakes

• Accepting alg: none. The spec allows an unsigned token whose algorithm is none. A server that does not reject these will accept any token an attacker forges, because there is no signature to fail. Production verifiers must require a specific expected algorithm.
• Algorithm confusion. If a server verifies with whatever algorithm the token header claims, an attacker can take an RS256 setup, switch the header to HS256, and sign a forged token using the public key as the HMAC secret. The fix is the same: pin the expected algorithm on the server instead of trusting the header.

Read tokens safely

A JWT often contains real session data, so decoding one on a random website means handing that data to a stranger. The JWT Decoder decodes locally in your browser, so the token is never sent anywhere. For the precise definitions of the claims and the token structure, the authority is RFC 7519, which specifies JSON Web Tokens in full.