Cookie and Session vs Token
Cookies, sessions, and tokens explained together. How server side sessions differ from stateless token auth like JWT.
Session based auth stores the user's login state on the server and uses a cookie just to reference it. Token based auth puts the user's identity directly inside a signed token, so the server does not need to store anything.
Cookie and Session vs Token at a glance
| Cookie and Session | Token | |
|---|---|---|
| Where state lives | On the server, in a session store | Inside the token itself, self contained |
| What the client holds | A cookie with a session ID | A token, often a JWT, sent with each request |
| Scalability | Needs a shared session store across servers | Stateless, any server can verify the token |
| Revoking access | Easy, delete the session on the server | Harder, tokens are valid until they expire |
| Typical use | Traditional server rendered web apps | APIs, mobile apps, single page applications |
| Payload visibility | Session ID is meaningless without the server | Token payload can be decoded by anyone, though not modified |
When to use each
Choose Cookie and Session when
- You are building a traditional server rendered web app.
- You want to revoke a user's access instantly by deleting their session.
- Your app runs on a small number of servers that can share a session store.
Choose Token when
- You are building a stateless API consumed by mobile apps or single page apps.
- You need to scale across many servers without a shared session store.
- You want the server to verify identity without a database lookup on every request.
How session based auth works
When a user logs in, the server creates a session and stores it, often in memory or a database, then sends the browser a cookie containing just the session ID. On every future request, the browser sends that cookie back, and the server looks up the session to know who the user is. The actual user data never leaves the server.
How token based auth works
With token based auth, commonly using a JWT, the server signs a token that contains the user's identity directly and hands it to the client. The client sends that token with every request, usually in an Authorization header, and the server just verifies the signature. There is no database lookup needed, because the token itself proves who the user is.
A frequent follow up is how you revoke a JWT before it expires, since there is no server side session to delete. Common answers include keeping a short lived token expiry, maintaining a blocklist of revoked tokens, or using a refresh token you can invalidate.
Frequently asked questions
Is a JWT the same as a cookie?
No. A JWT is a token format that contains signed data. It can be stored in a cookie, in local storage, or sent in a header, while a traditional session cookie just holds a reference ID with no real data inside it.
Which is more secure, sessions or tokens?
Neither is inherently more secure, they have different risk profiles. Sessions are easy to revoke but need a shared store. Tokens scale well but are harder to revoke early and must be handled carefully to avoid exposure in client side storage.
Why can anyone read a JWT's contents?
A JWT is signed, not encrypted, by default. The signature proves it has not been tampered with, but the payload itself is just base64 encoded and readable by anyone who has the token.
Want more interview ready comparisons?
Browse every Cookie and Session vs Token style breakdown, or explore the full question library.
All comparisons Browse questions