How Cookies Track You Across the Web

A cookie is a small text file that a web server instructs a browser to store on the user's device. Every time that browser makes a subsequent request to the same domain, it attaches the stored cookie automatically. That attachment is the core of the tracking mechanism — the server does not need to re-identify the visitor from scratch because the browser volunteers the identifier on every request.

This piece covers the machinery of cookie-based tracking: how identifiers are written and read, how third-party scripts extend that process across unrelated websites, and where the system produces results that differ from what users commonly expect.

How a Cookie Actually Records and Replays Your Identity

When a browser loads a webpage, the server's HTTP response may include a Set-Cookie header. That header contains one or more name-value pairs — for example, a session token or a long-lived visitor identifier — along with attributes that govern the cookie's scope and lifespan. The browser stores these pairs in a local cookie jar associated with the originating domain.

On every subsequent HTTP request to that domain, the browser appends a Cookie header containing the stored values. The server reads those values and matches them against its own records. If the cookie holds a persistent identifier, the server can link the current visit to every previous visit that carried the same value, regardless of how much time has passed or what content the user viewed in between.

First-party cookies are set by the domain whose address appears in the browser's address bar. A news site that sets a cookie on news-example.com can read that cookie only when the browser is on news-example.com. The tracking scope is, in principle, limited to that single domain's own pages.

Third-party cookies extend the scope dramatically. When a webpage embeds a resource — an image, a script, an advertisement frame — from a different domain, the browser makes a separate HTTP request to that external domain. That external domain can set its own cookie. Because the same external domain's resources appear on thousands of unrelated websites, its cookie travels with the browser across all of them. Each request carries the same identifier, and the external domain's servers accumulate a record of which sites the browser visited, in what order, and at what times.

Tracking pixels operationalize this at minimal data cost. A one-pixel transparent image embedded in a webpage or email triggers an HTTP GET request to the tracker's server. The request carries the cookie, the referring URL, the browser's IP address, and the timestamp. No visible content is exchanged; only the metadata travels, and that metadata is sufficient to log the visit.

The Technical Components That Make Cookie Tracking Operate

The HTTP protocol. Cookie transmission is built into HTTP itself. The Set-Cookie and Cookie headers are defined in RFC 6265. Every standard browser implements this exchange automatically, which is why cookie-based tracking requires no plugin, no download, and no explicit action from the user.

The browser's cookie store. Browsers maintain a persistent, domain-keyed store for cookies. The store enforces the Domain and Path attributes set by the server, and it respects the Expires or Max-Age attributes that control how long a cookie persists. A session cookie with no expiry attribute is deleted when the browser closes; a persistent cookie with a far-future expiry can survive for years.

Third-party script loaders. Publishers embed JavaScript from advertising networks, analytics platforms, and social widgets by adding a <script> tag pointing to an external domain. When the browser executes that script, the script can itself write additional cookies, read existing ones on the third-party domain, and transmit collected data back to the network's servers. Because the script runs in the context of the publisher's page, it has access to the page URL, which becomes part of the behavioral record.

The SameSite and Secure cookie attributes. These are server-side directives that constrain how cookies travel. SameSite=Strict prevents a cookie from being sent on any cross-site request; SameSite=Lax allows it only on top-level navigations. Secure restricts transmission to HTTPS connections. These attributes limit certain attack vectors but do not by themselves prevent intentional third-party tracking by the domain that set the cookie.

Autofill and credential systems. Cookie tracking is distinct from the mechanism by which a browser or password manager matches saved credentials to a site. How autofill matches credentials to a domain relies on domain verification logic, not on cookie values — though both systems use the domain as an anchor.

Where Cookie Tracking Breaks Down or Produces Unexpected Results

Browser partitioning and third-party cookie blocking. Several browser engines have introduced storage partitioning, which keys the cookie store not just by the cookie's origin domain but also by the top-level site the user is visiting. A tracker's cookie set while the user is on site-a.com is stored in a separate partition from the same tracker's cookie set on site-b.com. The tracker's server receives two different identifiers and cannot link the two sessions. The tracking mechanism still operates within each site; cross-site linkage is what breaks.

Cookie deletion and its limits. Deleting cookies from the browser removes the stored identifiers, but it does not erase the records the tracker's server has already assembled. A server-side behavioral profile built over months persists after a client-side deletion. When the browser next visits a tracked page, a new cookie is issued, and a new accumulation begins — but the old record remains on the server.

Cookie re-spawning via local storage. Some tracking implementations store an identifier in browser local storage or IndexedDB in addition to a cookie. If the cookie is deleted but local storage is not cleared, a script can read the local storage value and write it back into a new cookie, effectively restoring the identifier. This technique is sometimes called a "zombie cookie."

Login-based tracking bypasses cookies entirely. When a user is authenticated with a service — logged into an email platform, a social network, or a content site — that service can track behavior using server-side session records tied to the account, without relying on cookie identifiers at all. Cookie blocking does not affect this pathway. Data removal services that submit opt-out requests to data brokers address a different layer of this problem; how an opt-out request is actually processed describes that mechanism separately.

Browser fingerprinting as a parallel channel. Cookie tracking and browser fingerprinting are distinct mechanisms. Fingerprinting derives an identifier from the combination of browser version, installed fonts, screen resolution, time zone, and other attributes — none of which requires writing anything to the user's device. Blocking or deleting cookies does not disrupt fingerprint-based identification.

What Audits and Privacy Standards Actually Measure About Cookie Tracking

The FTC has addressed cookie-based tracking under its authority over unfair or deceptive trade practices. Its guidance distinguishes between cookies necessary for a service to function — maintaining a shopping cart, preserving a login session — and cookies deployed for behavioral advertising without adequate disclosure. The FTC's framework focuses on whether consumers received meaningful notice and had a real choice, not on whether cookies were technically present.

Technical privacy audits of websites typically use automated scanners that load a page in a controlled browser, capture all Set-Cookie headers, and classify each cookie by its origin domain (first-party or third-party), its declared purpose, and its expiry. These audits produce an inventory of cookies present at page load. They do not capture cookies set after user interaction, cookies injected by dynamically loaded scripts, or data transmitted by tracking pixels that do not set cookies at all.

Consent management platforms, required under certain regulatory frameworks, present a cookie banner and record the user's choice. What the audit log captures is the fact of consent or refusal and the timestamp — not whether the downstream tracking scripts actually honored the signal. Verification that a "reject all" choice suppressed third-party cookie writes requires a separate technical measurement, not just a consent log entry.

The concept of data minimization — collecting only what is necessary for a stated purpose — appears in FTC guidance and in various state-level privacy statutes. An audit can confirm whether a cookie's declared retention period matches its actual expiry attribute. It cannot confirm what the receiving server does with the data after it arrives, nor whether the server-side retention policy matches what was disclosed to users. Separately, monitoring services that watch for personal data appearing in data broker databases — described in detail in how a removal service's monitoring actually works — operate at a different layer and do not interact with the cookie mechanism directly.

Cookie-based tracking is a direct consequence of how the HTTP protocol was designed: the browser announces its stored identifiers on every request, and servers use those identifiers to assemble longitudinal records. The same mechanism that keeps a user logged in to a banking site also enables a third-party advertiser to observe that user's path across thousands of unrelated pages — the protocol does not distinguish between the two uses.

Note: This explains how digital privacy and security tools work technically. It is not legal or cybersecurity advice, and it is not a substitute for a reader's own judgment about a real security concern. Check the cited sources for current guidance.