Every time you log into a web application, a small object with three sections decides whether your next request is yours or an impostor’s. It is called a JSON Web Token (JWT), and its success comes from a counterintuitive property: the server does not need to store anything about you to verify that the token is authentic.
In this guide we will look at what those three dot-separated sections hide, why they are necessary, and where their real security limits lie. You do not need to be a cryptography expert to follow along, but we are not going to stay at the surface either.
The shape of a JWT: header.payload.signature
A JWT is a string of text split into three segments separated by dots:
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3In0.mNnw9_yYJN8FO_jJ_ZhQZc5rBs0Each segment is a JSON object encoded in Base64URL, a variant of Base64 that replaces the + and / characters with - and _ and drops the trailing = padding, so the result can travel in a URL or a cookie without escaping issues.
The first part, the header, declares two fields: the signing algorithm (alg) and the type (typ, normally JWT). The second is the payload, which carries the claims: the user, the issuer, the expiration date, and any extra data the application wants to attach. The third is the signature, the element that gives this object all of its strength.
Why the signature does not encrypt your token
Let us clear up a common misunderstanding: a JWT is not encrypted. The header and payload are only Base64URL-encoded, and anyone can decode them and read their contents. The security does not come from hiding the content but from the signature, which guarantees two things: that the token has not been altered since it was issued, and that it comes from whoever claims to have issued it.
Depending on the algorithm, the signature is computed in one of two ways. With HMAC (the HS256, HS384, and HS512 algorithms), issuer and receiver share a symmetric secret: the signature is a hash of the header and payload combined with that secret through a specific construction (HMAC-SHA). With asymmetric cryptography (RS256, ES256, EdDSA), the issuer signs and the receiver verifies with its public key, so only the holder of the private key can mint valid tokens.
The signature is always computed over the exact string header.payload. That is why changing even one character in the payload makes verification fail: the hash changes completely (the avalanche effect).
How a server verifies in three steps
When a server receives a JWT, it does not query its database to compare. It does this:
- Split the token on the dots and take the signature (third segment).
- Recompute the signature with the key that matches the algorithm declared in the header.
- Compare the result with the received signature. If they match and the expiration (
exp) has not passed, the token is valid.
That statelessness is the big advantage: the application can scale horizontally without sharing a central session, because each server validates the token on its own. It is also why JWTs are so widely used in APIs and microservice architectures.
The attacks that expose a misconfigured JWT
Convenience has a price, and there are three classic flaws worth knowing:
The alg=none hole. Some old libraries accepted tokens without a signature. An attacker would simply strip the signature, change the algorithm to none, and the server would accept the token with whatever payload the attacker wanted. Modern libraries always verify that the algorithm is on an explicit whitelist.
Confusing the verification key. In asymmetric algorithms such as RS256, the client knows the public key. If a server expects RS256 but accepts HS256, an attacker can sign the token with the public key (which now plays the role of the HMAC secret) and the server accepts it. It is the very same key, but used with a weaker algorithm.
Reading the token without encrypting it. Because the header and payload are in plain text, any sensitive data in the payload (a password, a card number) is exposed to whoever intercepts the token. That is what the JWE standard is for, which does encrypt the content. The practical rule: never put anything in a JWT you would not want to display publicly.
The lifecycle: expire, revoke, rotate
A verified token is not a token forever. The exp claim sets the expiration date and should always be short (minutes or a few hours). Because a JWT is autonomous and immutable, it cannot be force-revoked: once issued, it stays valid until it expires. That is why the best strategy is to issue a short-lived access token alongside a long-lived refresh token, stored on the server, which lets the session be renewed without asking for credentials again.
Understanding the anatomy of a JWT is not a theoretical exercise: it is the difference between a robust session and an entry vector for an attacker. The next time you inspect a token in your browser’s developer tools, you will know what each of its three parts contains and why the signature is the piece that must never fail.
