How JWTs actually work, explained with a real token

A JWT (JSON Web Token) looks like gibberish at first glance — a long string of characters separated by two dots — but it's actually three separate pieces, each Base64URL-encoded, glued together: a header, a payload, and a signature. Understanding what each piece does, and crucially what it doesn't do, clears up most of the confusion people have around JWTs the first time they work with authentication.

The header is the smallest piece, and it's mostly metadata — typically just the signing algorithm (like HS256 or RS256) and the token type. Decode it and you'll see something like {"alg": "HS256", "typ": "JWT"}. It tells whoever's verifying the token how the signature was produced, so they know how to check it.

The payload is where the actual claims live — the data the token is carrying. This commonly includes a subject (often a user ID), an expiration time, an issued-at time, and whatever application-specific data you've decided to include, like a role or permission level. This is the part people most often misunderstand: the payload is encoded, not encrypted. Base64URL encoding is trivially reversible by anyone — it's not a secret-keeping mechanism, it's just a text-safe way to represent binary-ish data. Anyone holding a JWT can decode the payload and read every claim inside it without needing any secret at all.

The signature is the piece that actually provides security, and it works differently from the other two. It's computed by taking the header and payload, running them through a signing algorithm along with a secret key (or a private key, for asymmetric algorithms), and producing a cryptographic signature. When a server receives a token, it recomputes this signature using its own copy of the secret and checks whether it matches the signature attached to the token. If even one character of the header or payload changed, the recomputed signature won't match, and the server knows the token was tampered with.

This is the core distinction that trips up a lot of people building authentication for the first time: decoding a JWT requires no secret and proves nothing about authenticity. Verifying a JWT requires the secret (or the correct public key) and is what actually confirms the token is legitimate and unmodified. A token can be perfectly readable and still completely invalid if its signature doesn't check out.

This has real implications for how you use JWTs. Never put anything genuinely sensitive directly in the payload — a password, a full credit card number, anything you wouldn't want a user (or anyone who intercepts the token) to be able to read directly, since the payload is always readable by design. And always verify the signature server-side before trusting any claim in the payload — checking a token's expiration or role claim without first verifying its signature means trusting data that could have been forged.

The three-part structure also explains why JWTs are popular for stateless authentication: a server can verify a token's authenticity using just the secret it already has, without needing to look anything up in a database — the token itself carries everything needed to confirm who the user is and that the claim hasn't been tampered with, at least until it expires.

Paste any JWT into our JWT Decoder to see this breakdown in real time — header, payload, and expiration status, decoded entirely in your browser, with nothing sent anywhere.