Understanding HTTP Cookies: Origins, Creation, and Best Practices

HTTP cookies, often simply called “cookies”, have existed for a long time but are still frequently misunderstood; many think they are backdoors or viruses while overlooking how they work and their essential role in web development.

Cookie Origins

Early web applications struggled to maintain state because a server could not tell whether two requests came from the same browser. The simplest solution was to embed a token in a page and return it on the next request, typically via hidden form fields or URL query strings, which was error‑prone. In 1994 Lou Montulli of Netscape applied the concept of “magic cookies” to web communication while building the first shopping‑cart application. His documentation formed the basis of RFC 2109 and later RFC 2965, and Netscape browsers supported cookies from their first version.

What Is a Cookie

A cookie is a small plain‑text file stored by the browser on the user’s computer. It contains no executable code. A web page or server instructs the browser to store information according to a specification, and the browser sends that information back in subsequent requests via the Cookie header, allowing the server to identify the user. Most login‑required sites set a cookie after successful authentication; the cookie itself is harmless data.

Creating a Cookie

Servers create a cookie by sending a Set-Cookie HTTP header. The header format is:

Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

The first part, value, is usually a name=value string, though browsers accept other formats. When a cookie is set, its value is sent back to the server in the Cookie header on each request.

Cookie Encoding

Only three characters—semicolon, comma, and space—must be URL‑encoded according to the original spec, but most implementations encode the entire value. The expires option specifies when the cookie should stop being sent; if omitted, the cookie lasts only for the current session and is deleted when the browser closes.

Domain Option

The domain attribute defines which host(s) the cookie will be sent to. By default it is the host that set the cookie, but it can be broadened (e.g., domain=yahoo.com) to cover subdomains. The browser matches the cookie’s domain against the request host from the end of the string.

Path Option

The path attribute restricts a cookie to URLs whose path begins with the specified value. It works similarly to the domain attribute; the most specific path takes precedence.

Secure Option

The secure flag has no value; it indicates that the cookie should only be sent over HTTPS connections, protecting it from being transmitted in clear text.

Cookie Maintenance and Lifecycle

A cookie can include any number of options in any order. Changing a cookie’s value requires sending another Set-Cookie header with the same name, domain, and path. Modifying any option (e.g., changing the path) creates a distinct cookie.

Using Expiration Dates

When an expires date is set, the cookie becomes persistent. Changing only the value does not alter the expiration date; to turn a persistent cookie into a session cookie, set its expiration to a past date.

Automatic Deletion

Session cookies are deleted when the browser closes.

Persistent cookies are deleted when their expiration date passes.

Browsers may delete cookies when the total number exceeds the per‑domain limit.

Cookie Limits

Original specifications limit each domain to 20 cookies (later increased in some browsers) and a total size of 4 KB for all cookies sent to the server.

Subcookies

To store more data within the cookie limit, developers use subcookies—multiple name=value pairs encoded into a single cookie value (e.g., name=a=b&c=d&e=f).

Cookies in JavaScript

JavaScript accesses cookies via the document.cookie property, which mirrors the behavior of the Set-Cookie and Cookie headers. Setting a cookie is done by assigning a properly formatted string to document.cookie. Reading returns a semicolon‑separated list that must be parsed manually.

HTTP‑Only Cookies

Introduced in IE6 SP1, the HttpOnly flag tells browsers not to expose the cookie to JavaScript, helping mitigate XSS attacks. Modern browsers (Firefox, Chrome, Opera) support this flag, but it cannot be set via JavaScript.

Summary

Cookies remain a fundamental yet often misunderstood part of the web. Proper understanding of their creation, options, limits, and security considerations is essential for building reliable and safe web applications.