Why internet "cookies" are named after a Unix programming trick
In 1994, Netscape programmer Lou Montulli needed a way for websites to remember users without storing massive amounts of data on servers. He adapted a Unix concept called a "magic cookie"—a small packet of data passed between programs. This allowed shopping carts to work, paving the way for modern e-commerce.
The Stateless Web and the Memory Problem
The Hypertext Transfer Protocol was engineered as a stateless communication system. In the early days of the World Wide Web, this design was an asset. A client requested a specific file, the server delivered it, and the connection closed immediately. The server retained no recollection of who had just visited, nor did it attempt to connect consecutive requests from the same user. This stateless architecture kept servers lightweight, resilient, and capable of handling distributed traffic across an emerging global network.
As the web evolved from a repository of academic documents into an interactive commercial platform, this lack of memory became a major technical hurdle. In 1994, engineers at Netscape Communications were tasked with solving a practical problem for the telecommunications company MCI, which wanted to build an online commerce application. An online store required a reliable shopping basket: when a visitor added an item on one page and navigated to another, the website needed a mechanism to remember what was in the basket without forcing the server to maintain open connections or store state databases for millions of anonymous visitors.
Borrowing a Concept from Unix
To solve the state problem, Netscape programmer Lou Montulli drew upon an established concept from Unix systems known as the "magic cookie." In Unix computing, a magic cookie was a small, opaque token or packet of data passed between programs. The receiving program did not need to understand or modify the contents of the token; it simply had to hold onto the token and return it unchanged during subsequent interactions to authenticate or maintain context, a pattern commonly used in environments such as the X Window System.
Montulli realized that this client-side storage model could be adapted to web architecture. Rather than requiring web servers to manage state on their own hardware, the server could issue a small string of text to the user's web browser. The browser would store this text locally and transmit it back to the server with every future request. By offloading data storage to the client, web servers could instantly identify returning users and keep track of sessions while maintaining the efficiency of the underlying stateless protocol.
The Mechanics of HTTP Cookies
The implementation of HTTP cookies relies on standard HTTP headers exchanged during a browsing session. When a user accesses a website, the server can include a Set-Cookie header in its response. This header specifies a name-value pair along with optional directives that govern how the browser should handle the data. The browser parses this directive, saves the data on the user's device, and automatically appends a Cookie header containing the relevant name-value pairs to every subsequent request directed to that same domain.
To manage security and data lifespan, cookie specifications include various attributes. An expiration date or maximum age determines whether a cookie is a temporary session cookie—discarded when the browser closes—or a persistent cookie stored across sessions. The Domain and Path attributes restrict which web addresses can receive the stored data. Over time, security extensions were introduced, such as the Secure attribute, which limits cookie transmission to encrypted HTTPS connections, and the HttpOnly flag, which blocks client-side scripts from reading the cookie to protect against cross-site scripting attacks.
Silent Adoption and the Privacy Awakening
Netscape integrated cookie support into Netscape Navigator version 0.9beta in October 1994. The technology operated silently in the background, invisible to everyday users. Microsoft added cookie handling to Internet Explorer in version 2.0 in 1995. For the first few years, consumers interacted with shopping carts, customized page layouts, and password-protected portals without realizing that their browsers were systematically receiving and storing identification tokens.
Public awareness shifted dramatically in early 1996 after articles in major news outlets, including the Financial Times, revealed that websites were placing data files on personal computers to track user activity. The disclosure triggered widespread concern regarding digital privacy and user consent. Regulators, including the United States Federal Trade Commission, held hearings to examine how cookies were being utilized, prompting early standard-setting bodies like the Internet Engineering Task Force to formalize specifications defining how browsers should manage cookie boundaries.
First-Party Context Versus Third-Party Tracking
The technical debate surrounding cookies centered largely on the distinction between first-party and third-party data. A first-party cookie belongs directly to the domain visible in the browser's address bar. These cookies handle basic site functionality, such as keeping users logged in, remembering language preferences, and retaining shopping cart contents. Because they operate solely between the user and the specific site they chose to visit, first-party cookies generally posed fewer controversial privacy concerns.
Third-party cookies, by contrast, originate from external domains whose resources—such as advertising banners, tracking scripts, or embedded media—are hosted on the visited page. When a browser loads content from an advertising network across dozens of unrelated websites, that ad network can read and set its own third-party cookies on each visit. This enabled advertising networks to construct detailed profiles of an individual's browsing habits across the wider web, turning a simple session-management tool into a comprehensive engine for behavioral targeting.
Vulnerabilities, Regulation, and Modern Controls
Because cookies frequently store sensitive session identifiers, they became targets for network and web-application exploits. In session hijacking attacks, malicious actors intercept or steal unencrypted session tokens through network sniffing or cross-site scripting, allowing them to impersonate authenticated users. Another major vulnerability, Cross-Site Request Forgery, occurs when a malicious site tricks a user's browser into sending unauthorized requests along with their valid credentials to a targeted service.
In response to tracking and security concerns, the web ecosystem underwent significant regulatory and architectural changes. Legal frameworks, such as the European Union's ePrivacy Directive and the General Data Protection Regulation, mandated clear user notice and consent before non-essential cookies could be stored. Modern web browsers have progressively blocked third-party tracking cookies by default and implemented security controls like the SameSite attribute, which restricts when cookies are sent with cross-site requests to mitigate unauthorized data transmission.
Key takeaways
•HTTP cookies were created in 1994 by Lou Montulli at Netscape to give the stateless web a way to remember user sessions without overloading servers.
•The name derives from 'magic cookies' in Unix programming, which are small, opaque data tokens passed between programs without modification.
•While first-party cookies enable essential features like shopping carts and logins, third-party cookies allowed ad networks to track browsing behavior across different websites.
•Modern web security and privacy regulations have restricted third-party tracking while introducing safeguards like HttpOnly and SameSite flags.