Cookies: How a Stateless Protocol Remembers You

The problem cookies solve#

HTTP is stateless. The server keeps no record of what a client asked for before, and every request is judged entirely on its own contents. That is a deliberate choice and a good one — it is what lets a server handle enormous numbers of clients without tracking any of them.

But a shopping site needs to know that the person adding a second item is the same person who added the first. Nothing in the request says so. Two requests from the same browser are, as far as HTTP is concerned, unrelated.

That distinction is worth being precise about, because the most common incomplete answer to a cookie question stops at “the website saves a cookie” without ever connecting the identifier to the stored record.

Vocabulary, before anything uses it#

The four components#

A complete answer to any cookie question names all four of these. Three of them are easy and the fourth is the one people leave out.

1. A cookie header line in the HTTP response — Set-Cookie:, sent once, when the site first decides to identify this browser.
2. A cookie header line in every subsequent HTTP request — Cookie:, sent by the browser automatically, without the user doing anything.
3. A cookie file kept on the user’s host, managed by the browser, holding which value goes with which site.
4. A back-end database at the website, where the actual information is stored against that identifier.

The exchange, first visit and every visit after#

First visit. The browser sends an ordinary request with no cookie, because it has none for this site. The server sees a request it does not recognise, generates a unique identifier, creates a row in its database keyed by that identifier, and puts the identifier in the response:

HTTP/1.1 200 OK
Date: Sun, 06 Sep 2026 14:22:07 GMT
Set-Cookie: id=1678
Content-Type: text/html

... the page ...

The browser stores 1678 in its cookie file, filed under this site.

Every visit after that, for as long as the cookie lasts — the next page, or a week later — the browser attaches it without being asked:

GET /cart HTTP/1.1
Host: shop.example.com
Cookie: id=1678

The server reads 1678, looks up that row, and now knows everything it previously stored about this browser: what is in the cart, what was bought before, what to recommend. It can update the row and the next request will see the update.

Browser holds the identifier  ·  Server holds the information

Notice what the server never had to do: keep anything in memory between the two requests. It stored the row, forgot the client entirely, and was reminded of which row to read when the client came back carrying the number.

What cookies are used for, and what they cost#

And the cost, which belongs in a complete answer because it is not a side note:

A site with a cookie on your browser can build a record of everything you do on it, across visits, indefinitely. If you have ever supplied a name or an email address, that record has your name on it. Cookies set by a domain other than the one in the address bar — third-party cookies, typically from advertising or analytics services embedded in many sites — let the same record span sites you never connected to each other.

Worked example#

Step 1 — Start at the first visit and name what the site creates. Two things, not one: a unique identifier, and a row in the back-end database keyed by it. Saying only “it creates a cookie” has already lost half the mechanism.

Step 2 — Follow the identifier through all four places. Out in Set-Cookie on the response; into the browser’s cookie file; back in the Cookie header on later requests; used as the key into the database. Trace it in that order and the four components appear on their own.

Set-Cookie → cookie file → Cookie → database row

Step 3 — Say what is stored where, explicitly. The browser holds the identifier and nothing else of substance. The purchases are rows in the site’s own database. This sentence is what separates a complete answer from a vague one.

Step 4 — Close the loop on a later visit. When the customer returns, the browser sends the identifier, the site reads the matching row, and it can display past purchases and append new ones. State the update as well as the lookup — a purchase record is written to as well as read.

Practice#

1. Name the four components of the cookie mechanism.
2. Which of the two cookie headers is a response header, and which is a request header? Say which appears more often and why.
3. A student writes “the site stores your order history in a cookie.” What is wrong with that, and what is stored instead?
4. Do cookies make HTTP stateful? Answer carefully.
5. A user visits a site for the first time. What two things does the site create, and in what order do they appear in the response?
6. Give three things a site can do with a cookie identifier that it could not do without one.
7. A user clears their cookie file and returns to a shopping site. What happens, and is their purchase record gone?
8. Explain in two sentences why cookies raise a privacy concern, without using the word “tracking” as an explanation on its own.

Solutions#

1. Response header, request header, cookie file, database. A cookie header line in the HTTP response (Set-Cookie); a cookie header line in subsequent HTTP requests (Cookie); a cookie file kept on the user’s host and managed by the browser; and a back-end database at the website.
2. Set-Cookie out, Cookie back. Set-Cookie is the response header, server to browser. Cookie is the request header, browser to server. Cookie appears far more often, because it is attached to every subsequent request, while Set-Cookie is typically sent once when the identifier is issued.
3. The cookie holds an identifier, not the data. The order history is not in the cookie. The cookie holds a unique identifier, often just a number. The order history is a row in the site’s back-end database, and the identifier is the key used to find it.
4. No, they add an identifier. No. HTTP remains stateless: the server keeps no memory between requests and each request is still interpreted on its own contents. Cookies let the client carry an identifier that the server uses to look up state it stored elsewhere. The state is in the database, not in the protocol.
5. A unique identifier and a database entry. It creates a unique identifier for this browser, and an entry in its back-end database keyed by that identifier. The identifier then appears in the response in the Set-Cookie header.
6. Authorization, carts, recommendations. Recognise a logged-in user without re-asking for credentials on every page; keep a shopping cart attached to one buyer across separate requests; and use a record of past activity to choose what to recommend. Maintaining user session state in a web application is an equally good fourth.
7. They become a new user; the old record survives but is unreachable. The browser has no cookie to send, so the site does not recognise the request and issues a fresh identifier and a fresh database entry. The old purchase record still exists on the server, but nothing now links this browser to it. Logging in restores the connection, because authentication identifies the user by other means.
8. Correlation across requests and across sites. A site that can recognise the same browser across every request can build a permanent record of everything done there, and if the user ever supplied a name or an email address, that record is attached to a real identity. When the cookie is set by a third party embedded in many different sites, the same record spans sites the user never connected to one another.

Test-readiness checklist#

• ☐  I can name the four components without looking, including the database.
• ☐  I can say which cookie header travels in which direction, and how often each appears.
• ☐  I can state precisely what is stored in the browser and what is stored on the server.
• ☐  I can answer “do cookies make HTTP stateful?” correctly and explain why.
• ☐  I can draw the first visit and a later visit as two separate exchanges.
• ☐  I can give four genuine uses of a cookie identifier.
• ☐  I can say what happens when a user clears their cookies, including what survives.
• ☐  I can explain the privacy concern in terms of correlation rather than as a slogan.

Frequently asked questions#

Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written.