Where the HTTP cookie comes from

A small thing carrying a hidden message — like its namesake. Photo: Lorax, CC BY-SA 3.0.

The HTTP cookie is named after the Unix magic cookie, an old computing term for an opaque token that one program hands to another and gets back later without ever looking inside it. Lou Montulli, an engineer at Netscape, picked the name in June 1994 when he needed to make a stateless protocol behave as if it had a memory. He dropped the magic — partly for brevity, partly because he liked how cookie sounded — and shipped the idea in the first beta of the Netscape browser four months later. Almost everything controversial about cookies in 2026, from shopping carts to third-party tracking to the consent banner on every site you visit, traces back to that one design decision and to a property of HTTP that the cookie was invented to paper over.

HTTP forgets everything

The problem cookies solve is that HTTP is stateless by design. Each request from a browser to a server is, in principle, independent: the server answers it and forgets it ever happened. There is no built-in notion of this is the same visitor who asked for a page a moment ago. For serving static documents — the original purpose of the web at CERN — statelessness is a feature, because it keeps servers simple and lets any request be routed to any machine.

The moment anyone tried to build a transaction on top of the web, statelessness became the obstacle. A shopping cart is the canonical example: you add an item on one page, navigate to another, and the cart has to remember what you put in it. Without state, the server cannot tell that the second request came from the same person as the first. The options in 1994 were all bad: store every partial transaction on the server keyed by something, or thread an identifier through every URL by hand. Netscape was building an e-commerce system for MCI, and MCI specifically did not want its servers holding partial transaction state for every browsing visitor. The state had to live on the client.

Montulli's June 1994 idea

Lou Montulli's solution was to let the server hand the browser a small piece of data and ask the browser to send it back on subsequent requests to the same site. The server sets it once; the browser stores it and re-attaches it automatically. The server reads it on the next request and recognises the visitor. State now lives on the client, the server stays stateless between requests, and the shopping cart works.

Montulli conceived the mechanism in June 1994 while at Netscape Communications. He and John Giannandrea — later a senior figure at Google and then Apple — wrote the initial Netscape cookie specification the same year. The first browser to support it was version 0.9beta of Mosaic Netscape, released on 13 October 1994. The very first deployed use was almost quaint: the Netscape site used a cookie to check whether a visitor had been there before. Montulli filed for a patent in 1995; it was granted as US 5,774,670 on 30 June 1998.

The mechanics have barely changed in thirty years. A server includes a Set-Cookie header in its response; the browser stores the name/value pair and re-sends it in a Cookie header on every subsequent matching request. The whole thing is a few lines of header text. The simplicity is exactly why it spread.

Why it is called a cookie

The name was already in use in computing long before the web. A magic cookie — usually shortened to cookie — is an opaque token of agreement between cooperating programs: a handle, a transaction ID, a piece of data that one party stores and hands back later without needing to understand its contents. Eric Raymond's Jargon File defines it as "a handle, transaction ID, or other token of agreement between cooperating programs." The standard analogy is a coat-check ticket: the number on the ticket means nothing to you, but it lets the cloakroom return the right coat.

The term predates the web by at least fifteen years in documented use. It appears in the UNIX Programmer's Manual, 7th Edition from Bell Labs in January 1979, in the man page for the fseek routine: the value returned by ftell is described as a position in bytes on Unix, but "on some other systems it is a magic cookie, and the only foolproof way to obtain an offset for fseek." In other words, an opaque token whose internal meaning you are not meant to inspect — you just hold it and give it back when you want to return to that position. That is exactly what an HTTP cookie is: the browser holds a token it does not interpret and hands it back to the server that issued it.

Montulli had picked up the term, by his own account, in an operating-systems course. He decided to drop the magic and just call them cookies, for brevity and because he liked it. The aesthetic choice has had thirty years of consequences for how the public talks about web privacy, because cookie is friendly and edible and sounds harmless, which the third-party tracking variety emphatically is not. (For other cases where a working name stuck for non-technical reasons, see why git is called git and why Apache is called Apache.)

RFC 2109, and the standard that took seventeen years

Netscape's cookie behaviour was a de facto standard for years before it became a real one — implemented from the browser, documented in a short specification, copied by every other browser because sites depended on it. The IETF began trying to formalise it in April 1995. The first standards-track result was RFC 2109, published in February 1997 by David Kristol and Lou Montulli. Notably, RFC 2109 already recommended that browsers restrict third-party cookies by default — the privacy concern was visible to the standards authors from the very start, and they tried to design against it.

That recommendation was largely ignored by browser vendors, because turning off third-party cookies broke the advertising and analytics businesses already building on them. RFC 2965 superseded RFC 2109 in October 2000, introducing a Set-Cookie2 header that almost nobody implemented. The standard that finally described what browsers actually do — rather than what the IETF wished they would do — was RFC 6265, published in April 2011 by Adam Barth, which deprecated Set-Cookie2 and documented the real-world behaviour. It took seventeen years from invention for the standard to catch up with the implementation, and it caught up by surrendering to it. The pattern is familiar: the same gap between an elegant standard and the protocol people actually run shows up in SSH's slow march to RFC.

The privacy turn started in 1996

The mechanism Montulli designed was for first-party state — a site remembering its own visitors. The problem is the structure does not distinguish the site you are looking at from a site that has embedded an image or script on the page you are looking at. If an advertising network serves a tracking pixel on a thousand different sites, it can set and read its own cookie on all thousand, and it sees the same browser move across all of them. This is the third-party cookie, and it turns the cart-remembering mechanism into a cross-site identity tracker.

The public found out fast. On 12 February 1996, the Financial Times published an article that introduced cookies to a general audience and raised the privacy implications directly — barely sixteen months after the feature shipped. The coverage prompted US Federal Trade Commission hearings on online privacy in 1996 and 1997. The concern that RFC 2109's authors had baked into the very first standard was now a public controversy, and it has never gone away.

What followed was three decades of escalation. Browsers added cookie controls; advertisers routed around them; the EU's ePrivacy Directive of 2002 (the "cookie law") and later the GDPR produced the consent banner that now greets you on essentially every site. Browser vendors began deprecating third-party cookies outright — Safari and Firefox blocking them by default, and Google's long, repeatedly-delayed effort to remove them from Chrome. The mechanism that was invented to make a shopping cart work is being slowly walked back because the same mechanism makes surveillance trivial.

SameSite, HttpOnly, and the slow hardening

The other thirty-year story is security. A cookie sent automatically on every matching request is exactly what an attacker wants for cross-site request forgery: if your bank session lives in a cookie, a malicious page can make your browser send an authenticated request to the bank without your knowledge. The defences accreted over time as attributes on the cookie itself. Secure (send only over HTTPS) and HttpOnly (hide the cookie from JavaScript, to blunt cross-site scripting theft) came relatively early. The SameSite attribute — which tells the browser not to attach the cookie on cross-site requests — was the significant late addition, with browsers eventually defaulting it to SameSite=Lax so that the dangerous cross-site behaviour is off unless a site explicitly opts in.

Each of these is a patch on the original design's single most consequential property: the browser re-sends the cookie automatically, without asking. That automatic re-attachment is what makes cookies useful and what makes them dangerous, and almost every cookie-related security feature since 1994 is an attempt to constrain it without breaking the thing it was built for.

A short close

The HTTP cookie exists because HTTP forgets everything between requests, and someone needed a stateless protocol to remember a shopping cart. Lou Montulli borrowed a fifteen-year-old Unix term for an opaque token, dropped the word magic, and shipped the idea in a 1994 browser beta. The name stuck because it was friendly; the mechanism stuck because it was simple; and both the privacy problem and the security problem were visible almost immediately — the Financial Times wrote the scare piece in 1996, and the first standard tried to restrict third-party cookies in 1997. Thirty years of consent banners, SameSite attributes, and Chrome deprecation announcements are all downstream of a coat-check ticket for a web that was never designed to remember you.