# JWT vs Session

URL: https://softwaredictionary.org/compare/jwt-vs-session
Last updated: 2026-09-30

In short: A JWT is a signed token that carries the user's identity, so servers verify it without a lookup, while sessions keep state on the server behind a random ID.

## What is the difference between JWT and session authentication?

A JSON Web Token (JWT) is a compact, signed string with three parts: a header, a payload of claims such as the user ID and expiry time, and a signature. In session-based authentication, the server creates a session record after login, keeps it in memory, a database or a cache, and sends the browser a random session ID, usually in a cookie.

The essential difference is where the state lives. With sessions the server holds the truth, so each request needs a lookup, but logging someone out or changing their permissions takes effect immediately. A JWT is self-contained: any server with the verification key can trust it without shared storage, which suits distributed systems and APIs, but a stolen or outdated token stays valid until it expires.

They are frequently combined. Many systems pair short-lived JWT access tokens with a refresh token that is stored on the server and can be revoked, and a JWT can itself live in an `HttpOnly` cookie just like a session ID. The token format and the place where it is stored are separate decisions.

A common misconception is that JWTs are encrypted. A standard signed JWT is only Base64URL-encoded, so anyone can read its payload; the signature just prevents changes. Never put secrets in a JWT, and don't assume it is automatically more secure or more scalable than a well-run session store.

| Aspect | JWT | Session |
| --- | --- | --- |
| Where state lives | In the token itself, held by the client | On the server, in memory, a database or a cache |
| What the client holds | A signed token with claims like user ID and expiry | A random, meaningless session ID |
| Verification | Check the signature with a key; no lookup | Look up the session ID in the session store |
| Logout and revocation | Hard before expiry; needs short lifetimes or a denylist | Instant: delete the session on the server |
| Scaling | Any server with the key can verify it | Servers need a shared session store |
| Size | Hundreds of bytes or more, sent with every request | A small ID of a few dozen bytes |
| Best for | APIs, mobile apps, microservices and single sign-on | Traditional web apps with server-rendered pages |

## Choose JWT when

- Many services must verify users without sharing a session database.
- Clients include mobile apps or third-party API consumers, not just browsers.
- You use single sign-on or an identity provider that issues tokens.

## Choose Session when

- You need instant logout or immediate permission changes.
- Your app is mostly a browser-based site served by one backend.
- You want the simplest secure setup, with an HttpOnly session cookie.

## Frequently asked questions

**Are JWTs more secure than sessions?**

Not inherently. Both are secure when implemented well; sessions are easier to revoke, while JWTs are harder to invalidate early and should be short-lived.

**Where should I store a JWT in the browser?**

An `HttpOnly`, `Secure` cookie keeps it out of reach of JavaScript and XSS attacks, though you then need CSRF protection. Storing tokens in `localStorage` is simpler but exposes them to any script on the page.

**Can you log out a user with JWT?**

Not directly, because the token stays valid until it expires. Common fixes are short expiry times, revocable refresh tokens and a server-side denylist of revoked token IDs.

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt