JWT and session cookies are the two dominant patterns for keeping a user logged in across requests, and they embody fundamentally different trust models. Session cookies are an opaque handle to server-side state; JWTs are self-contained, cryptographically signed tokens that carry their own claims. Each model has sharp edges that only surface at scale or under attack — the right choice depends on your architecture, not on fashion.
Side-by-Side Comparison
JWT (JSON Web Token)
Pros
- Stateless — the server validates by signature, no database lookup required
- Scales horizontally — any instance can verify a token without shared session storage
- Carries claims (user ID, roles, expiry) inline — no extra round trip to look them up
- Works cross-domain — useful for single-sign-on across subdomains or services
- Standardized (RFC 7519) with broad library support in every language
- Great for short-lived API access tokens issued by an OAuth/OIDC provider
Cons
- Hard to revoke — a stolen token is valid until it expires unless you maintain a denylist
- Token bloat — claims travel in every request, increasing header size
- Cannot invalidate a session server-side without re-introducing state (denylist)
- Authorization changes (role revoked) do not take effect until the token refreshes
- Easy to misuse — algorithms like "none" and weak symmetric secrets are classic pitfalls
- Not a good fit for long-lived browser sessions on their own — pair with refresh tokens
Session Cookies
Pros
- Trivial revocation — delete the server-side session and the cookie is instantly useless
- Opaque to the client — no claims leak, no token reuse risk if cookies are HttpOnly
- Small on the wire — a session ID is a few dozen bytes regardless of user data
- Authorization changes (role revoked, password reset) take effect on the next request
- Mature browser security model — SameSite, Secure, HttpOnly all work as expected
- Well-suited to long-lived web sessions behind a single domain
Cons
- Requires server-side session storage — Redis, database, or in-memory
- Harder to scale horizontally — every instance needs access to shared session state
- Session lookup on every request adds latency and load
- Cross-domain SSO is awkward — cookies do not flow across unrelated domains
- CSRF is a real risk — mitigations (SameSite, tokens) are mandatory, not optional
- Not directly usable by mobile apps or third-party services — needs a token bridge
The Verdict
For a traditional server-rendered web app on a single domain, session cookies are almost always the better default — they are simpler, revocable, and lean on the browser's mature security model. Reach for JWTs when you have a stateless API serving multiple clients (web, mobile, third-party), a microservices architecture where shared session storage is awkward, or an OAuth/OIDC single-sign-on flow. Even then, use short-lived access tokens plus refresh tokens, never long-lived JWTs as the sole session mechanism. The question is rarely "JWT or cookies" — it is "where do I want the state to live."
Frequently Asked Questions
Put it into practice
Open our free in-browser tool — no signup, no ads, runs entirely on your device.
Open Tool Now