TechCompare LogoTechCompare

JWT vs session cookies: which should your web app use for login?

For a single web app with its own back end, a server session in an HttpOnly cookie is simpler and easier to revoke. JWTs earn their keep when many services need to check identity without sharing a session store.

A classic session cookie holds a random ID, and the server looks up the session in a database or cache on every request. A JWT carries the user's claims inside the token, signed so the server can check them without a lookup. Both can travel in a cookie. The real difference is where the state lives and what that means for logout, scaling and size.

By TechCompare · Updated

Topic
JWT vs session cookies
Session design
Category
Best Practices
Settings that keep tokens safe
Try the live JWT Decoder. Decode a token, read its time claims, and verify the signature in your browser.
Edit in the full tool

How this is calculated

Server sessions make logout instant: delete the session and the cookie is worthless. They need a shared store once you run more than one server, but Redis or a database handles that for most apps. JWTs skip the lookup, which is why they suit microservices, APIs called by mobile apps, and single sign on across domains, where each service verifies the token with a public key. The cost is revocation. A JWT stays valid until exp unless you add a deny list, which brings back the lookup you were avoiding. Size matters too. A session ID is a few dozen bytes, while a signed JWT with a handful of claims is often several hundred, sent with every request, and a single cookie is limited to about 4 KB in most browsers. Storage is the other big question. A JWT kept in localStorage can be read by any script that runs on the page, so one cross site scripting bug leaks it. Putting the JWT in an HttpOnly, Secure, SameSite cookie protects it from scripts, but then you need the same CSRF care as with session cookies. Many teams end up with a hybrid: a session cookie for the browser and short JWTs for calls between services.

Verdict

Choose server sessions for a typical web app, and keep the cookie HttpOnly, Secure and SameSite. Choose JWTs for APIs with many independent verifiers, keep them short lived, and avoid localStorage for tokens that grant real access.

More JWT scenarios

Decode vs verify
Anyone can read a JWT. Only a signature check with the right key tells you who wrote it.
View details ➜
exp, nbf and iat
The three time claims, what each one means, and how verifiers compare them with the clock.
View details ➜
Fixing jwt expired
Why fresh tokens fail with "jwt expired" and how clock drift, leeway and milliseconds cause it.
View details ➜

Related guides

Password manager guide
The other half of keeping accounts safe.
View guide ➜

Frequently asked questions

Are JWTs more secure than session cookies?
Not by default. Both rely on HTTPS and careful storage. Sessions are easier to revoke, while JWTs are easier to verify across services. Security depends on how you store, check and expire them.
Where should I store a JWT in the browser?
In an HttpOnly, Secure, SameSite cookie when you can, so page scripts can't read it. If a single page app must hold it in memory, keep it short lived and refresh it through a cookie based endpoint.
Can a JWT be used as a session ID?
It can, but then you lose instant logout unless you also track sessions on the server. If you're going to keep server state anyway, a random session ID is smaller and simpler.

Related tools

Text Encoding Converter

Convert between Text, Base64, Binary, Hexadecimal, and Decimal formats.

Use tool ➜

Unix Timestamp

Convert between Unix timestamps and human-readable dates.

Use tool ➜

JSON Formatter

Validate, format, and minify JSON. Browse it as a tree, run JSONPath queries, compare two documents, or validate against a JSON Schema.

Use tool ➜