A JWT, short for JSON Web Token, is a compact, signed token that carries claims about a user or request from one system to another. After you log in, a server can hand you a JWT that says, in effect, "this is user 42 and the token expires at noon." On later requests you send the token back, the server verifies its signature, and if it is valid the server trusts the claims without looking anything up in a database. That property, trusting the signature instead of stored state, is what makes JWTs popular for authentication in 2026.
How a JWT is built
A JWT is three Base64-encoded parts joined by dots: header.payload.signature. The header says what algorithm signed the token. The payload holds the claims, which are simple key-value facts like the user ID and an expiry time. The signature is computed from the header and payload using a secret or private key, and it is what proves the token has not been tampered with.
// a JWT looks like this, three dot-separated chunks
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiIsImV4cCI6MTcwMH0.K3pQ...signature
Anyone can decode the header and payload, because Base64 is encoding, not encryption. What they cannot do is change the payload and produce a matching signature without the key. That is the whole security model.
Signed versus encrypted: a key misconception
This trips up almost everyone, so be clear about it.
| Property |
A standard signed JWT |
An encrypted token |
| Can the payload be read? |
Yes, by anyone |
No, only by the holder of the key |
| Can it be tampered with? |
No, the signature breaks |
No |
| Safe to store secrets in? |
Never |
Still avoid it where possible |
| Common case |
The default JWT you will meet |
A separate, less common encrypted variant |
The takeaway: a normal JWT proves who issued it and that it was not changed, but it does not hide the contents. Never put passwords or private data in the payload.
Why JWTs are useful
Traditional sessions store state on the server: a session ID maps to user data in a store the server must check on every request. JWTs flip this. The token itself carries the data, signed, so the server can verify it independently. That makes it easy to scale across many servers, since none of them need to share a session store, and it works cleanly for APIs and mobile clients.
The trade-off is revocation. A session can be deleted instantly. A JWT is valid until it expires, so you cannot easily cancel one mid-flight without extra machinery. JWTs are most often used to prove identity, so it helps to know the difference between authentication and authorization before you build with them.
How to use JWTs safely
- Keep expiry times short, often minutes to an hour, and issue a separate refresh token for longer sessions.
- Always verify the signature on the server; never trust a token just because it decodes.
- Send tokens over HTTPS only, and consider storing them in a secure, HttpOnly cookie to reduce theft risk.
- Never put sensitive data in the payload, since it is readable by anyone holding the token.
- Have a revocation plan, such as a short expiry plus a server-side denylist for compromised tokens.
What to skip
- Skip long-lived tokens with no expiry. A stolen token then works forever. Pair short expiry with refresh tokens.
- Skip storing secrets in the payload. It is readable. Treat the payload as public.
- Skip the none algorithm. Accepting unsigned tokens is a classic vulnerability; reject it explicitly.
- Skip JWTs when a simple session fits. For a single traditional web app, server sessions are often simpler and easier to revoke.
FAQ
Is a JWT encrypted?
Usually not. A standard JWT is signed, which proves it was not altered, but the payload is only Base64-encoded and anyone can read it. Encryption is a separate, less common variant. Do not store secrets in the payload.
How is a JWT different from a session?
A session stores user data on the server and gives the client an ID. A JWT carries the data itself, signed, so the server verifies it without a lookup. That makes JWTs easier to scale but harder to revoke instantly.
Where should I store a JWT in the browser?
A secure, HttpOnly cookie is generally safer than local storage because scripts cannot read it, reducing the impact of cross-site scripting. Always send it over HTTPS.
Can a JWT be revoked?
Not easily on its own; it stays valid until it expires. Teams handle this with short expiry times, refresh tokens, and sometimes a server-side denylist for tokens that must be cancelled early.
Where to go next
Learn how authentication differs from authorization, understand what a REST API is, and see what an API endpoint does.