A lot of beginners think Cookies, Sessions, and JWT are competing technologies.
They're not.
- Cookies are a way to store data in the browser.
- Sessions are a way to store user state on the server.
- JWT is a way to store user information inside a signed token, usually without server-side session storage.
1. Why Do We Need Authentication?
HTTP is stateless.
That means every request is independent.
Example:
GET /profile
The server receives:
- Method
- Headers
- Body
But it has no memory of previous requests.
Imagine:
POST /login
You log in successfully.
Five seconds later:
GET /profile
How does the server know this request is from the same logged-in user?
It doesn't—unless some form of identity is sent with every request.
This is where Cookies, Sessions, and JWT come in.
2. Cookies
A cookie is a small piece of data stored by the browser.
The server tells the browser to save it.
Example login response:
HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123
The browser stores:
sessionId = abc123
Every future request to the same domain automatically includes it:
GET /profile
Cookie: sessionId=abc123
Notice:
The frontend doesn't need to manually add the cookie.
The browser handles it automatically.
Important
A cookie is just storage.
It doesn't authenticate users by itself.
It can store:
- Session IDs
- JWTs
- User preferences
- Theme
- Language
Think of it like a small key-value storage managed by the browser.
3. Sessions
A session means the server stores the user's login state.
Example:
User logs in.
Server creates:
Session ID:
abc123
Server database (or memory):
abc123
↓
User ID = 42
Name = Alice
Role = Admin
Expires = 30 minutes
The server sends only the session ID:
Set-Cookie:
sessionId=abc123
Browser stores:
sessionId=abc123
Future request:
Cookie:
sessionId=abc123
Server:
Find session
↓
User ID = 42
↓
Authenticated
Session Flow
User Login
│
▼
Server creates Session
│
▼
sessionId = abc123
│
▼
Browser stores Cookie
│
▼
Every request sends Cookie
│
▼
Server looks up session
│
▼
User authenticated
Advantages
- Easy logout (delete the session)
- Server controls everything
- Easy to invalidate sessions
- Sensitive user data stays on the server
Disadvantages
Server must store every user's session.
If you have:
5 million users
You need somewhere to store 5 million sessions.
Large applications often use shared stores like Redis so multiple backend servers can access the same sessions.
4. JWT (JSON Web Token)
JWT takes a different approach.
Instead of storing user data on the server...
...the server stores it inside the token.
Example payload:
{
"userId": 42,
"role": "admin",
"exp": 1783000000
}
The server signs it with a secret key.
Result:
eyJhbGciOi...
This long string is the JWT.
Login:
POST /login
Server:
Create JWT
↓
Return JWT
Browser stores it.
For future requests:
Authorization:
Bearer eyJhbGc...
Server verifies:
- Signature
- Expiry
- Integrity
If valid:
Authenticated.
JWT Flow
Login
│
▼
Server creates JWT
│
▼
Browser stores JWT
│
▼
Authorization:
Bearer <token>
│
▼
Server verifies signature
│
▼
Authenticated
5. Where Is JWT Stored?
JWT can be stored in:
- Memory
- Local Storage
- Session Storage
- Cookies
JWT is not tied to one storage mechanism.
Many people incorrectly think JWT always means Local Storage.
It doesn't.
6. Sessions vs JWT
Sessions
Browser
↓
sessionId = abc123
↓
Server
Session Table
abc123
↓
User 42
Server stores state.
JWT
Browser
JWT
↓
Server
Verify Signature
↓
Done
No session lookup is required if you're relying solely on the token.
7. Comparison
| Feature | Session | JWT |
| User data stored | Server | Token |
| Server storage | Required | Not required (for basic validation) |
| Easy logout | ✅ Yes | Harder (token remains valid until expiry unless additional revocation is implemented) |
| Horizontal scaling | Needs shared session storage | Easier because servers only need the signing key |
| Token size | Small (session ID) | Larger |
| Can carry user claims | No (stored on server instead) | Yes |
Cookie
↓
Storage mechanism
Session
↓
Authentication strategy
JWT
↓
Authentication token format
A cookie is not an alternative to JWT or sessions.
Examples:
Session Authentication
Cookie
↓
sessionId
↓
Server session
JWT Authentication
Cookie
↓
JWT
↓
Server verifies JWT
Or:
Local Storage
↓
JWT
↓
Authorization Header
JWT can live inside a cookie, and sessions almost always use a cookie to hold the session ID.
9. Security Considerations
Cookies
If marked as:
HttpOnly
JavaScript cannot read them.
This helps protect against XSS attacks.
Secure
Cookie is only sent over HTTPS.
SameSite
Helps protect against CSRF by controlling when cookies are sent on cross-site requests.
JWT
JWTs should always:
- Use HTTPS
- Have an expiration time
- Be signed with a strong secret or private key
- Avoid storing sensitive information (payload is encoded, not encrypted)
Interview Questions
Is a cookie encrypted?
No.
Cookies are plain text unless your application encrypts their contents before storing them.
HTTPS protects cookies in transit, not while they're stored in the browser.
Can JWT be stored in cookies?
Yes.
This is a common production setup.
Can sessions work without cookies?
Yes.
A session ID could be sent in a custom header or URL, though cookies are by far the most common and recommended transport.
Which is better: Session or JWT?
Neither is universally better.
- Sessions are great when you want simple logout, server-side control, and easy revocation.
- JWTs are useful for stateless APIs, distributed systems, and scenarios where carrying user claims in the token is beneficial.
The best choice depends on your application's requirements.
Notion Notes (Short Version)
Cookies
- Small key-value data stored by the browser.
- Set by the server using
Set-Cookie. - Automatically sent with future requests to the same domain.
- Can store session IDs, JWTs, preferences, etc.
- Common security flags:
HttpOnly,Secure,SameSite.
Sessions
- Server stores user login state.
- Browser stores only a session ID (typically in a cookie).
- Each request includes the session ID.
- Server looks up the session to authenticate the user.
JWT (JSON Web Token)
- Signed token containing user claims.
- Usually sent in the
Authorization: Bearer <token>header, but it can also be stored in a cookie. - Server verifies the signature instead of looking up a server-side session.
Key Difference
| Cookies | Sessions | JWT |
| Browser storage mechanism | Server-side authentication state | Signed authentication token |
| Stores small data | Stores user state on server | Stores claims inside the token |
| Often used with sessions or JWT | Usually uses cookies for session ID | Can be stored in cookies or browser storage |
This understanding is strong enough for most backend interviews and gives you a solid foundation for topics like OAuth, refresh tokens, and modern authentication flows.