Cookie vs Session
Client-side vs server-side state
Cookies and sessions are both mechanisms for maintaining state in stateless HTTP, but they store data in different places. Cookies live in the browser and travel with every request. Sessions store data on the server and use a cookie only to hold an identifier.
Cookie
A cookie is a small piece of data (up to ~4KB) that a web server sends to the browser, which stores it and includes it in subsequent requests to that server. Cookies are set via the Set-Cookie HTTP header and are automatically sent back via the Cookie header. They have attributes controlling scope (Domain, Path), lifetime (Expires, Max-Age), and security (Secure, HttpOnly, SameSite). Common uses include session IDs, authentication tokens, user preferences, tracking, and shopping carts. Because cookies are stored on the client and sent with every request, they should never contain sensitive data in plaintext.
Session
A session is a server-side mechanism for storing user-specific data across multiple HTTP requests. When a user first connects, the server creates a session with a unique identifier (session ID) and stores data in server memory, a database, or a cache like Redis. The session ID is sent to the client as a cookie (or less commonly, in the URL). On subsequent requests, the server reads the session ID from the cookie and retrieves the associated data. Sessions can store much more data than cookies (limited only by server resources), and the data never leaves the server, making sessions more secure for sensitive information.
Key Differences
- **Storage location**: Cookies are stored in the browser. Session data is stored on the server. - **Size limits**: Cookies are limited to ~4KB. Sessions can store arbitrary amounts of data on the server. - **Security**: Cookie data is visible to the client (unless encrypted). Session data stays on the server — only the session ID travels to the client. - **Lifetime**: Cookies can persist indefinitely (persistent cookies) or until the browser closes (session cookies). Server sessions typically expire after inactivity. - **Scalability**: Cookies scale effortlessly (data lives on clients). Sessions require server-side storage that must be shared across server instances (sticky sessions or centralized stores like Redis). - **Relationship**: Sessions typically use cookies to store the session ID. They're not alternatives — sessions are built on top of cookies.
When to Use Each
**Use cookies** for small, non-sensitive data that needs to persist across browser sessions: language preferences, theme settings, non-critical feature flags, or consent records. Also used as the transport mechanism for session IDs and JWTs. **Use sessions** when you need to store sensitive or large amounts of user-specific data: authentication state, shopping cart contents, multi-step form progress, or role-based permissions. The data stays on your server where you control access.
Analogy
**A cookie** is like a wristband you get at a concert — you carry it with you, it identifies your ticket type, and security checks it every time you enter a section. But it can only hold a small amount of info and anyone can see what's printed on it. **A session** is like a coat check — you hand over your coat (data) and receive a small numbered ticket (session ID). Your belongings are stored securely behind the counter. You just carry the ticket, and present it to retrieve your stuff.