Cookies vs. Sessions

Cookies and sessions are related, but they are not the same thing.

A cookie is a small piece of data that a server asks the browser to store and send back on later requests. A session is server-side state associated with a user or client over time. In many web applications, the session is identified by a session ID stored inside a cookie, which is why the two terms are often mixed together.

The cookie mechanism is part of HTTP. A server sends a Set-Cookie header, and the browser may store the value along with attributes such as:

• Expires or Max-Age for lifetime
• Domain and Path for scope
• Secure so it is only sent over HTTPS
• HttpOnly so JavaScript cannot read it
• SameSite to limit when the browser sends it on cross-site requests

On later matching requests, the browser sends the cookie back in the Cookie header.

A session is different. The session usually lives in server memory, a database, or a cache such as Redis. It might store the user ID, login time, CSRF secret, shopping basket, locale, or other per-user state. The browser does not normally hold that state directly. It only holds the session identifier.

This creates an important security property. If the cookie contains just an opaque session ID, the client cannot change their privileges by editing the cookie value into “admin=true”. The server still looks up the session record and decides what the ID means. Of course, if an attacker steals the session ID, they may still hijack the session, which is why secure cookie attributes and transport security matter.

Cookies also have hard practical limits. Browsers restrict the size of each cookie, usually around 4 KB, and they send relevant cookies on every matching request. Large or numerous cookies add overhead to every page load, API call, image fetch, or form submission under that scope. Sessions avoid that wire cost because the heavy state stays on the server.

The tradeoff is operational. Sessions consume server-side storage, need expiry and cleanup, and may require a shared session store when multiple application instances handle the same users. If the session backend fails, authenticated requests can fail even though the browser still has the session cookie.

There are also combinations beyond the classic pattern. A cookie can hold state directly, such as a signed preference blob, without any server session at all. A session can be tracked without cookies by using headers or URL rewriting, although that is less common on the modern web and often less safe.

The security risks differ too. Cookies are exposed to cross-site request forgery if they are sent automatically and the application lacks CSRF defences. JavaScript-readable cookies are exposed to XSS. Sessions are exposed to fixation, hijacking, and poor invalidation if session IDs are predictable or not rotated after login.

The useful rule is this: a cookie is a transport container on the client side, while a session is continuity state on the server side. They often work together, but they answer different design needs.