How cookies carry data and when they are sent

A cookie is a name-value pair sent in the Set-Cookie response header. The browser stores it and includes the matching Cookie header on subsequent requests to the same origin. Because cookies travel with every request, large or numerous cookies increase bandwidth use, especially on mobile connections.

Each cookie is limited to roughly 4 KB and browsers cap the total number per domain, often in the low hundreds. Exceeding these limits causes older cookies to be dropped without warning.

  • Cookies are always sent to the server; they are not a client-only store.
  • Modern alternatives such as localStorage and IndexedDB never leave the browser and support larger data volumes.

Scope defined by Domain and Path attributes

The Domain attribute decides which hosts receive the cookie. When omitted, the cookie is sent only to the exact host that set it. Setting Domain to a parent domain makes the cookie available to that domain and all its subdomains. A server cannot set a Domain value outside its own hierarchy.

The Path attribute further narrows delivery. The cookie is included only when the requested URL begins with the specified path. This lets a site isolate cookies to specific sections without affecting the rest of the application.

  • Omitting Domain is more restrictive than setting it to the current host.
  • Path matching is prefix-based and case-sensitive.

Expiration rules and session versus permanent cookies

Cookies without an Expires or Max-Age attribute are session cookies. They are deleted when the browser session ends, though some browsers restore them after a crash or restart. Permanent cookies carry either an Expires date in HTTP-date format or a Max-Age value in seconds. When both attributes are present, Max-Age takes precedence because it is relative to the moment the cookie is set rather than to the client's clock.

To delete a cookie immediately, re-issue it with the same name, path, and domain but with an Expires date in the past or a Max-Age of zero or negative.

  • Session cookies can persist across restarts in browsers that restore sessions.
  • Max-Age is less error-prone than Expires when server and client clocks differ.

SameSite controls first-party and third-party use

The SameSite attribute determines whether a cookie is sent with cross-site requests. Strict sends the cookie only on same-site navigations. Lax allows it on top-level navigations but blocks most embedded requests. None permits cross-site use but requires the Secure flag.

First-party cookies match the registrable domain and scheme of the top-level page. Third-party cookies come from a different site and are increasingly blocked by default in major browsers to limit tracking.

  • SameSite=None must be paired with Secure.
  • Strict mode is safest for authentication cookies that should never leave the origin site.

Security flags and common misconceptions

The Secure flag ensures a cookie travels only over HTTPS. The HttpOnly flag prevents JavaScript from reading the cookie via document.cookie, reducing the impact of cross-site scripting attacks. Partitioned cookies, when supported, further isolate storage by top-level site.

A frequent misconception is that cookies can hold arbitrary application data. Their small size, automatic transmission, and server round-trips make them unsuitable for large or sensitive client-only information. Another misconception is that clearing cookies always logs a user out; many sites now rely on server-side session storage keyed by the cookie value, so the session may survive on the server even after the cookie is removed.

  • HttpOnly cookies are still sent with JavaScript-initiated requests such as fetch.
  • Review site permissions regularly to understand which origins can set cookies in your browser.