What is a JWT, and how is it verified?
A JWT (JSON Web Token) is how a server hands you a piece of paper that says "this person is logged in" — one that you can carry around and show to other services, and that nobody can quietly edit without getting caught. No database lookup required to check it. Here's what's actually inside one, and how the "verified" part works.
Three parts, glued with dots
A JWT is just a string, and if you look closely you'll notice it has exactly two
dots in it, splitting it into three sections: header.payload.signature. Each
section is a chunk of JSON, encoded into a compact text format called
base64url (not encrypted — just encoded, so anyone can decode and read it).
The header says how the token is built — usually just the signing algorithm, like HS256 or RS256. The payload is the actual content: claims about the user, like their ID, their role, and when the token expires. The signature is the part that makes the whole thing trustworthy.
What the payload is not
It's tempting to treat the payload like a sealed envelope, but it isn't one. Because it's only base64-encoded, not encrypted, anyone who gets hold of the token — a nosy browser extension, a proxy, a curious developer — can decode the payload and read it in plain text. This is normal and expected. A JWT proves that the claims inside came from the server and haven't been tampered with; it does not hide them. If a token needs to carry a secret, that secret belongs somewhere else, not in the payload.
The signature is the whole point
Here's the part that actually matters: when the server first creates the token, it takes the header and payload, and runs them through a cryptographic signing step using a secret key only the server knows. That output becomes the signature, the third section glued onto the end.
Later, when the token comes back — attached to a request, usually in an
Authorization header — the server (or another service that shares the secret)
redoes that exact same signing step on the header and payload it just received,
and compares the result to the signature that's attached. If they match, the
token is provably unchanged since it was issued. If someone edited the payload
along the way — changing their role from user to admin, say — the signature
computed on the tampered data won't match the original one, and the token gets
rejected outright.
This is why verifying a JWT doesn't need a database round-trip. The server doesn't have to go look up "is this session still valid?" in a table; it just re-does a quick calculation and checks two strings match. That's most of why JWTs got popular for scaling logins across many servers — any server holding the shared secret (or, with RS256, the public key) can verify a token on its own, with no shared session store to keep in sync.
Two ways to sign
There are two common families. HS256 uses one shared secret: the same key both signs and verifies, which is simple but means every service that verifies tokens needs a copy of that secret. RS256 uses a public/private key pair — the server signs with a private key it keeps close, and hands out a public key that anyone can use to verify, but not to forge new tokens. RS256 is the safer choice when multiple independent services need to check tokens without all being trusted with the power to mint them.
What "expired" actually checks
Most JWTs carry an expiry timestamp in the payload (exp), and part of
verification is simply checking that timestamp against the current time. This
is a plain comparison, not a cryptographic one — but it only works because the
signature already guarantees nobody quietly pushed that expiry date into the
future after the token was issued. Expiry and signature verification work
together: one limits how long a valid token lives, the other ensures the token
you're looking at is the real one.
The takeaway
A JWT is a small, self-contained proof: a payload of claims, wrapped in a signature that only the issuing server (or its trusted key holder) could have produced. Verifying one is fast precisely because it's just a recalculation, not a lookup — but that speed only holds up because nothing in the token can be edited without breaking the signature. Read the payload, trust nothing until the signature checks out.
This explainer was made with LineLapse — type a topic, get a hand-drawn video. Make your own →