How a Tracker Cookie Survives a Browser Restart

When a browser closes and reopens, most of what it held in memory is discarded. Temporary state — form input, scroll position, the contents of a tab that was never bookmarked — disappears. Yet a subset of cookies remain intact across that boundary, available to the same tracking scripts the next time the user visits a site that loads them. That persistence is not accidental; it is the product of a specific instruction written into the cookie itself at the moment it was set.

This piece covers the mechanism by which a tracker cookie outlives a browser session: how the expiry attribute is written, where the browser stores the resulting file, and how third-party tracking networks exploit that storage to reconstruct a visitor's identity days or weeks after the original page load.

How the Expiry Attribute Keeps a Cookie Alive on Disk

A cookie is created when a server or a script running inside a page issues a Set-Cookie header or executes a document.cookie assignment. The simplest possible cookie has only a name and a value. Without any further attributes, the browser treats it as a session cookie — it lives in memory and is deleted when the browser process ends. The distinction between a session cookie and a persistent cookie is explained in detail in the piece on how a session cookie actually expires.

A tracker cookie that is designed to survive a restart carries an additional attribute: either Expires, which names an absolute date and time in UTC, or Max-Age, which names a number of seconds from the moment the cookie is set. When either attribute is present, the browser does not hold the cookie in memory. Instead, it writes the cookie — name, value, domain, path, flags, and calculated expiry timestamp — to a persistent storage file on the device's filesystem. On most desktop platforms this is an SQLite database maintained by the browser's profile directory. The file survives process termination because it is written to disk, not held in RAM.

At startup, the browser reads that database back into memory, filtering out any rows whose expiry timestamp is earlier than the current clock time. Cookies that have not yet expired are loaded and become available to matching requests immediately, before the user has navigated anywhere. From the perspective of a tracking script, the browser restart never happened: the identifier value it wrote weeks earlier is still present and will be sent in the Cookie request header the next time the script's origin is contacted.

The expiry values set by tracking networks are typically long. Durations of 365 days, 400 days (the current maximum that some browser engines enforce for script-set cookies), or 730 days appear in practice. A cookie set to expire in 400 days will survive not just a single restart but hundreds of them, persisting across operating system updates and browser version upgrades, as long as the profile directory remains intact.

Third-Party Cookie Tracking: The Components That Make It Work

The publisher page. A webpage served from a first-party origin (the domain the user navigated to) contains one or more references to resources — scripts, image pixels, iframes — hosted on a different domain. These cross-origin resource references are the entry point for third-party tracking. How that third-party cookie tracking pipeline operates at the request level is covered separately in the article on how a third-party cookie actually tracks you.

The tracking script. JavaScript delivered from the tracker's domain runs in the context of the publisher page. It issues a network request back to the tracker's own servers. Because that request crosses to the tracker's origin, any Set-Cookie response from the tracker's server is scoped to the tracker's domain, not the publisher's. The browser stores it under the tracker's domain key in the cookie database.

The cookie database. The browser's persistent cookie store is an SQLite file (or equivalent structured storage) keyed by domain, path, and cookie name. Each row records the expiry timestamp. The database is written synchronously enough that the cookie survives an unexpected browser crash as well as a clean shutdown.

The HTTP Cookie request header. On every subsequent request to the tracker's domain — regardless of which publisher page triggered it — the browser attaches the stored cookie value in the Cookie header. The tracker's server reads that value and uses it to look up or update a profile associated with that identifier. Because the same tracker script is embedded across many publisher sites, the tracker accumulates page-visit records from all of them, linked by the single persistent identifier.

The consent layer. In jurisdictions where cookie consent is required, a consent management platform may gate whether the tracking script is loaded at all. The technical relationship between consent signals and script execution is described in the article on how a cookie consent banner gates tracker scripts. If the script is blocked before it executes, no cookie is set and no cross-site identifier is written to disk.

Where Persistence Breaks Down or Produces Unexpected Results

Browser-enforced maximum ages. Some browser engines cap the effective Max-Age of a cookie set via JavaScript at 400 days, regardless of the value the script requests. A tracker that requests a 10-year expiry receives a cookie that will actually expire in roughly 13 months. The cap does not prevent re-setting the cookie on the next visit, but it means a user who does not revisit any site carrying that tracker for more than 400 days will lose the persistent identifier.

Intelligent Tracking Prevention and partitioning. Several browser engines implement storage partitioning for third-party contexts, meaning a cookie set by a tracker on Site A is stored in a partition keyed to Site A, and is not visible when the same tracker is contacted from Site B. This collapses the cross-site linking that makes third-party cookie tracking valuable. The cookie persists on disk, but it no longer functions as a cross-site identifier — it becomes, at most, a per-site identifier.

Profile deletion and private browsing. If the browser's profile directory is deleted, or if the session was conducted in a private or incognito window, the persistent cookie database is either wiped or never written to persistent storage in the first place. In private mode, cookies behave as session cookies regardless of their Expires attribute: they exist in memory for the duration of the private session and are discarded when that session ends.

Clock skew. The browser evaluates cookie expiry against the local system clock. If the system clock is set to a date far in the past, cookies that should have expired will appear valid. If the clock is set far in the future, cookies that should still be live will appear expired and will be deleted. This is an edge case in practice but can produce confusing behavior in testing environments or on devices with misconfigured time synchronization.

Fallback to browser fingerprinting. When persistent cookies are blocked or deleted, some tracking systems fall back to stateless identification techniques. Browser fingerprinting reconstructs a device identifier from the combination of browser version, installed fonts, canvas rendering output, and other observable attributes — without writing anything to disk. This technique is unaffected by cookie deletion because it stores no state on the client at all.

What Audits and Standards Reveal About Persistent Cookie Practices

The FTC has documented that tracking technologies, including persistent cookies, are used to build detailed profiles of consumer behavior across sites and over time. The agency's framework for online privacy identifies persistent identifiers as a category of data collection that warrants notice and choice mechanisms, particularly when the data is used for behavioral advertising. The FTC's analysis focuses on the downstream use of the collected data — the profile — rather than on the cookie file itself, which means a technical audit of cookie storage alone does not capture the full scope of what the FTC considers relevant to consumer privacy.

The GDPR and the ePrivacy Directive (in EU jurisdictions) require that non-essential cookies — a category that includes most third-party tracking cookies — be set only after affirmative user consent. Compliance audits in this context examine whether consent management platforms correctly suppress tracker scripts before consent is granted, and whether the consent signal is correctly transmitted to downstream data processors. What these audits do not assess is the technical durability of the cookie once consent is granted: a lawfully set persistent cookie still writes to disk, still survives restarts, and still sends its identifier on every matching request until it expires or is deleted.

The CISA guidance on web security does not address cookie tracking directly, but its broader advisories on browser security hygiene note that browsers maintaining large volumes of persistent state — cookies, cached credentials, stored tokens — represent an expanded attack surface if the device is compromised. In that context, the persistence mechanism that makes a tracker cookie useful to an advertising network is the same mechanism that makes it a recoverable artifact during forensic examination of a device.

No standard audit framework currently measures the accuracy of a tracker's cross-site profile against ground truth, because the profile itself is not disclosed to auditors. Audits can confirm whether a cookie was set with a given expiry value, whether it was scoped to the correct domain, and whether it was transmitted under HTTPS. They cannot confirm what the tracker's server did with the identifier value, how long the server-side profile was retained, or with whom it was shared.

The persistence of a tracker cookie across a browser restart is entirely a function of a single attribute in the cookie specification — an attribute that has existed since the earliest versions of the standard. The mechanism requires no exploit, no elevated privilege, and no user action beyond visiting a page that loads a third-party resource. Its durability is a design property of the web's cookie architecture, not a vulnerability in the conventional sense.

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.