HTTP Cookie

An HTTP cookie is a small named value that a server asks the browser to store with the Set-Cookie response header. The browser sends it back in the Cookie request header on later requests that match its rules, which lets a stateless protocol remember a login, a basket or a preference. The request header carries only the name and value, never the attributes. RFC 6265 is the specification that defines this mechanism, and MDN's guide to HTTP cookies is a good plain-language companion.

A cookie is sent to the server automatically with matching requests, while localStorage never leaves the browser unless your own code sends its contents. Cookies can carry flags such as HttpOnly and Secure, so scripts cannot read an HttpOnly cookie. LocalStorage is readable by any script on the page, which makes it a weaker home for session tokens. MDN notes that modern storage APIs are recommended for general client-side storage because cookies are sent with every request and can hurt performance.

RFC 6265 says browsers should support at least 4096 bytes per cookie, counting name, value and attributes, at least 50 cookies per domain and at least 3000 in total. These are minimums that servers should plan around, and real limits vary by browser, so test the browsers you support. MDN describes about 4 KB per cookie as the usual maximum. Keep cookies small, because they travel with every matching request, and store bulky data on the server.

Send a Set-Cookie header with the same name, domain and path as the original, and an expiry in the past or a Max-Age of zero or less. MDN describes this as the way to remove a cookie immediately. If any of the three identifying parts differ, the browser treats it as a different cookie and the original stays. This mismatch is the most common reason a logout appears to work while the user remains logged in.

A session cookie is a cookie with no Expires or Max-Age attribute, so the browser treats it as temporary and normally removes it when the session ends. The browser decides when that is, and MDN warns that session restore can keep session cookies alive indefinitely. A session cookie is not the same as a server-side session; it usually just carries an identifier. For login state, prefer a short lifetime plus server-side idle and absolute timeouts.

The usual causes are a different host, a path that does not match, a Secure cookie on a plain HTTP request, an expired lifetime, a SameSite restriction or a blocked third-party context. Work through them in that order using the browser's developer tools: the network panel shows Set-Cookie on responses and, for each request, which cookies were sent or filtered out, often with a reason. A cross-origin fetch also omits cookies unless credentials are enabled.

HttpOnly hides a cookie from page scripts, so document.cookie cannot read it, while the browser still sends it with requests. MDN notes it is still included on fetch and XMLHttpRequest calls. This limits cookie theft through cross-site scripting, because injected script cannot copy a session identifier. It does not stop injected script from acting as the user through requests that carry the cookie, so it reduces damage rather than preventing XSS. Preventing injection remains the real fix.

The Secure flag tells the browser to send the cookie only over encrypted connections, which means HTTPS. MDN notes that localhost is an exception for development. Current browsers also generally refuse to let an insecure response set or overwrite a Secure cookie, which blocks a trick where a network attacker plants a cookie. It only protects you if the whole site uses HTTPS, so pair it with redirects from HTTP and, where appropriate, Strict-Transport-Security.