HTTP Cookies and the Invention of State on the Stateless Web
HTTP cookies gave web applications a small client-side mechanism for carrying state across otherwise separate requests, enabling shopping carts and login sessions while also opening the door to cross-site tracking.
The early Web could fetch documents without remembering a visitor
HTTP was designed around requests and responses, not around a permanent conversational session between one browser and one server. A browser could request a document, receive it, and later make another request, but the protocol did not automatically tell the server that both requests belonged to the same shopping trip or logged-in user. Lou Montulli, then at Netscape, later described this as a practical problem in 1994 when developers wanted a shopping server to maintain a cart across page requests.[1] The challenge was to add useful memory without assigning every browser one universal identity that any website could read. Cookies became the answer: small pieces of state chosen by a server, stored by the browser, and returned on later requests that matched defined scope rules.
State did not mean keeping one network connection open forever
A cookie lets separate HTTP requests participate in a logical session. The transport connection can end, the user can click to another page later, and the browser can still present the state token that lets the server associate the new request with earlier activity.
Netscape’s cookie design scoped state to relevant hosts and paths
The early Netscape “Persistent Client State HTTP Cookies” specification described a mechanism in which a server sends cookie data and attributes to a browser, which later returns matching cookies in HTTP requests.[2] Attributes could constrain a cookie by domain and path and could determine whether it persisted beyond the current browser session. This model was intentionally narrower than a universal browser serial number. Montulli recalls opposing a proposal for a unique browser identifier because it would allow pervasive recognition across sites; domain-scoped cookies were intended to give individual sites memory without creating one global identity.[1] The design therefore embedded a privacy boundary from the beginning, even though later web composition would reveal a way around the designers’ expectations.
The browser became a controlled state store for servers
Cookies are not simply arbitrary files a website writes to disk. The user agent mediates storage and decides which stored name-value pairs are eligible to be returned based on cookie attributes and the request context defined by the evolving specifications.
Cookies enabled the commercial and personalized Web
Once a site could recognize a returning session, familiar application patterns became far easier. Shopping carts could survive navigation between product pages. Authentication systems could associate subsequent requests with a successful login. Sites could remember preferences without placing every setting in a URL. Analytics could count repeat visits. These were not cosmetic features; they helped transform the Web from a document-retrieval system into an application platform. The server could keep complex session data in its own database while placing only an opaque identifier in the browser, or it could encode small amounts of state directly in cookie values. Either way, the cookie provided continuity across otherwise independent HTTP requests.
A tiny mechanism created a much larger application abstraction
The cookie need not contain the shopping cart or user record itself. It can contain only a key that points to server-side state. A few bytes in an HTTP header can therefore anchor an arbitrarily rich session maintained elsewhere.
RFC 2109 tried to turn deployed behavior into an Internet standard
Cookies spread rapidly through browser and server implementations before the standards process fully caught up. RFC 2109, published in 1997, attempted to specify an HTTP state-management mechanism that would formalize behavior, improve interoperability, and address privacy concerns.[3] Standardizing an already popular browser feature was harder than designing on a blank sheet because compatibility with deployed sites constrained what could change. Some attributes and behaviors proposed by standards were not adopted uniformly. This gap between specification and implementation became a recurring feature of cookie history. The web platform evolves through a negotiation among documents, browsers, servers, and enormous amounts of existing content; a theoretically cleaner rule can fail if it breaks too many real sites.
Standards had to describe a moving target
Once millions of pages and browsers rely on an informal behavior, the installed base becomes part of the protocol. Cookie specifications repeatedly had to reconcile preferred semantics with what browsers and servers were already doing in practice.
Third-party content transformed site memory into cross-site tracking
Montulli has written that an important problem was not fully anticipated during the original cookie design: web pages can embed resources from other domains. If many unrelated sites load an image, script, or advertisement from the same third party, the browser may send that third party’s cookie during each embedded request. The third party can then correlate activity across sites even though the top-level pages belong to different publishers.[1] This turned a mechanism designed for scoped site memory into infrastructure for advertising profiles and behavioral tracking. The episode shows that privacy properties cannot be reasoned about from one protocol message alone. Composition matters. A boundary that looks local in an isolated request can become global when the same service is embedded everywhere.
RFC 2965 tried another redesign, but deployed compatibility remained stronger
RFC 2965 in 2000 defined a new HTTP state-management mechanism and introduced features intended to address limitations in earlier cookie behavior.[4] Yet its model did not replace the dominant “Netscape cookie” behavior across the Web. This is an instructive standards failure: a successor can be technically motivated and formally published while still losing to the accumulated compatibility requirements of existing implementations. Browser vendors and sites had already converged on practices that developers depended on. Any new mechanism faced the cost of running alongside the old one, supporting legacy quirks, and persuading an enormous ecosystem to change simultaneously.
RFC 6265 standardized the reality browsers had actually converged on
RFC 6265, published in 2011, took a more pragmatic approach by documenting the cookie syntax and semantics that user agents and servers needed for interoperability while acknowledging historical irregularities and security and privacy concerns.[5] The specification is a good example of standards work as archaeological engineering: sometimes the task is not to invent the ideal protocol but to precisely describe the de facto protocol that billions of interactions already depend on. Later browser policy added controls such as SameSite handling and restrictions on third-party cookies, but the core idea remains recognizable: servers set scoped state, browsers retain it, and matching requests return it.
Why cookies belong in the history of the Web
Cookies belong in CodeHistory because they solved one of the Web’s central transitions: moving from stateless document requests to stateful applications. A small browser-managed token enabled carts, logins, preferences, and server-side sessions, helping websites behave like ongoing software rather than isolated pages.[2][5] The same capability also created one of the Web’s defining privacy controversies when embedded third parties used cookies to correlate behavior across sites. That dual legacy is not accidental. Persistent state is powerful precisely because it links actions over time. Cookie history demonstrates that an enabling application primitive and a surveillance primitive can be the same mechanism viewed under different deployment relationships.
Works Cited
- 01Lou Montulli — The Reasoning Behind Web Cookies montulli.blogspot.com
- 02
- 03
- 04
- 05Barth — RFC 6265: HTTP State Management Mechanism rfc-editor.org
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead