Cookie

HTTP is stateless. Each request the browser sends arrives at the server with no memory of the request before it. Without help, the server cannot tell that the person loading the checkout page is the same person who logged in two clicks earlier. A cookie is the standard fix for that gap.

A cookie is just a name and a value, like session_id=8f3c2a, plus some attributes that control how the browser treats it. The total size is capped at roughly 4 KB per cookie, and browsers store around 50 cookies per domain. Anything bigger or more permanent belongs in a database, not a cookie.

The browser stores cookies per site. A cookie set by example.com is sent only back to example.com, never to a different domain. That scoping is what keeps your bank session from leaking to an unrelated page in another tab.

The server sets a cookie by adding a Set-Cookie header to its HTTP response, for example Set-Cookie: session_id=8f3c2a; Path=/; HttpOnly; Secure; SameSite=Lax. The browser reads that header and saves the cookie.

On every following request to that site, the browser automatically adds a Cookie header carrying the values back: Cookie: session_id=8f3c2a. The application does not have to ask for it; the browser sends it on its own. The server reads the value and looks up who that session belongs to.

Attributes decide the rules. Expires or Max-Age sets a lifetime; without one the cookie is deleted when the browser closes (a session cookie). HttpOnly hides the cookie from JavaScript so a cross-site scripting bug cannot read it. Secure means send only over HTTPS. SameSite controls whether the cookie rides along on requests started by other sites, which is the main defense against CSRF attacks.

A common pattern is the session cookie. The server stores the real user data server-side and the cookie holds only a random opaque session id. The alternative is a signed token, such as a JWT, stored in the cookie, where the data lives in the cookie itself and the server verifies a signature instead of doing a lookup.

Use cookies when the server needs the value on every request and the browser should attach it automatically. Authentication sessions are the textbook case, because the server must know who you are on each page load. Cookies are also good for small preferences like a language choice or a dismissed banner.

Do not put large or sensitive raw data in a cookie. It travels on every request, so a fat cookie slows down every single call, and a value the user can read or tamper with should never be trusted without a signature. For client-only state that the server never reads, localStorage is a better fit because it is not sent over the wire.

The big trade-off today is privacy and third-party cookies. A cookie set by a domain different from the page you are visiting, used for cross-site ad tracking, is being blocked by default in Safari and Firefox and was the target of Chrome's long phase-out effort. First-party cookies, set by the site you are actually on, remain the normal way to run a session and are not going away.

You log into github.com. GitHub checks your password, creates a server-side session, and responds with Set-Cookie carrying an opaque session id marked HttpOnly, Secure, and SameSite. Your browser saves it.

Now you click into a repository, open an issue, and edit your profile. Each of those is a separate HTTP request, and on each one your browser quietly attaches the session cookie. GitHub reads it, recognizes you, and serves your private data without asking you to log in again.

When you click Sign out, the server invalidates that session and sends a Set-Cookie that expires the value immediately, so the next request arrives with no valid cookie and you are back to being anonymous.