A JSON Web Token (JWT, often said “jot”) is a compact, self-contained way to carry verified information between two parties — most often to prove “this user is logged in.” Instead of the server storing a session in memory, it hands the client a signed token the client sends back with each request. Understanding its three parts demystifies modern authentication.
The anatomy: three dot-separated parts
A JWT looks like xxxxx.yyyyy.zzzzz — three Base64url chunks joined by dots. The header says which signing algorithm is used. The payload holds the “claims” — data like the user ID, roles, and an expiry time. The signature is the crucial part: it is a cryptographic seal over the header and payload, created with a secret only the server knows.
Why the signature is everything
Here is the key insight people miss: the payload is not encrypted — it is only Base64-encoded, so anyone can read it (paste a token into jwt.io and you will see the claims in plain text). What the signature guarantees is integrity: if an attacker changes a single character of the payload — say, flipping "role":"user" to "admin" — the signature no longer matches, and the server rejects it. The server trusts the token because only it could have produced a valid signature.
How a login flow uses it
The user logs in with a password once; the server verifies it and returns a JWT. From then on, the client attaches that token (usually in an Authorization: Bearer header) to every request. The server validates the signature and expiry on each call — no database lookup required — which is why JWTs scale well across many servers and APIs.
The security rules that matter
Because a JWT is a bearer token, whoever holds it is treated as the user, so a few rules are non-negotiable. Never put secrets in the payload — it is readable. Always set a short expiry and use refresh tokens for long sessions. Send tokens only over HTTPS, and store them carefully on the client (an HttpOnly cookie resists cross-site scripting better than localStorage). And reject the infamous alg: none attack by pinning the expected algorithm on the server. Follow those and JWTs are a solid, standard foundation for authentication.
Reading the three parts
A JWT is three Base64url-encoded segments joined by dots. The first is the header, which names the signing algorithm. The second is the payload, holding the claims. The third is the signature, which is what makes the whole thing trustworthy.
The critical point, and the one most frequently misunderstood, is that the first two parts are encoded, not encrypted. Anyone holding the token can decode and read them with no key at all. Paste a JWT into any decoder and the payload appears in plain text.
What this means for what you store
Because the payload is readable by the holder and by anyone who intercepts the token, it must never contain secrets. Passwords, payment details, government identifiers and private personal data do not belong in a JWT under any circumstances.
What belongs there instead is identity and authorisation information that the user is already entitled to know: a user identifier, a role, an expiry timestamp, the issuer. The signature does not hide any of this. What the signature provides is tamper detection: if someone edits the payload to change their role from user to admin, the signature no longer matches and the server rejects the token.
Standard claims worth knowing
Several claim names are registered and widely honoured. exp sets an expiry time, after which the token should be refused. iat records when it was issued. sub identifies the subject, usually the user. iss names the issuer and aud the intended audience, which together stop a token minted for one service being replayed against another.
Honouring exp is not optional in practice. A token without a meaningful expiry is a credential that works forever, and if it leaks there is no natural point at which the exposure ends.
Revocation is the hard part
The property that makes JWTs attractive is that a server can validate one using only the signing key, without a database lookup. That same property makes them awkward to cancel. A conventional session can be deleted server-side and is immediately dead; a signed token remains valid until it expires, because validation never consults any central record.
Teams generally resolve this in one of two ways. The first is to keep access tokens short-lived, often minutes, and pair them with a longer-lived refresh token that can be revoked centrally. The second is to maintain a denylist of revoked token identifiers, which reintroduces the lookup that JWTs were meant to avoid but only for the revocation check. Neither is free, and choosing between them is a real architectural decision rather than a detail.
One algorithm warning
Historically some libraries accepted a token declaring alg: none and skipped signature verification entirely, allowing anyone to forge any payload. Modern libraries reject this, but the lesson generalises: the server should decide which algorithms are acceptable, rather than trusting the algorithm named inside the token it is trying to validate.
Common questions
Is the data inside a JWT encrypted?
No. The payload is only Base64-encoded and anyone can read it. The signature protects integrity, not secrecy — never put sensitive data in a JWT payload.
What are the three parts of a JWT?
Header (the algorithm), payload (the claims like user ID and expiry), and signature (a cryptographic seal proving the token was not tampered with).
Where should I store a JWT in the browser?
An HttpOnly, Secure cookie is generally safer than localStorage because it is not readable by JavaScript, reducing XSS risk. Always use HTTPS.
How is a JWT different from a session cookie?
A session cookie is an opaque ID that maps to server-side state; a JWT carries the state itself, signed, so the server can verify it without a lookup.