Where Do Site Cookies Save

When a web server sets a cookie, the data does not stay on the server. It travels in an HTTP response header to the browser, which writes it to a reserved storage area on the local device. That storage area is managed entirely by the browser process, not by the operating system's general file system or by the web page itself.

This piece covers the storage layer: where the bytes land, how long they persist, which attributes control their scope, and what the storage record does and does not reveal to an observer reviewing it later.

How a Browser Receives and Writes a Cookie

The sequence begins at the server. When a server wants to store state on a client, it includes a Set-Cookie header in its HTTP or HTTPS response. That header carries, at minimum, a name-value pair. It may also carry directives: Expires or Max-Age, Domain, Path, Secure, HttpOnly, and SameSite.

The browser parses the header and evaluates the directives before writing anything. If the Secure flag is present, the browser only accepts the cookie over an encrypted HTTPS connection. If HttpOnly is present, the browser blocks JavaScript from reading the stored value — the cookie is accessible only through the HTTP request cycle itself. If no Expires or Max-Age is supplied, the browser treats the cookie as a session cookie: it is held in memory and discarded when the browser session ends. If an expiry date is supplied, the browser writes the cookie to persistent storage, where it survives restarts until the stated date passes.

Persistent cookies are written to a structured database file maintained by the browser. In most major browser engines, this is an SQLite database stored inside the browser's application-data directory on the local file system. The exact path varies by operating system and browser profile, but the format is consistently a table with columns for the cookie name, value, host, path, expiry timestamp, and flag states. A session cookie, by contrast, is held only in the browser's in-memory cookie store and is never written to that database file.

On every subsequent HTTP request to a matching origin, the browser reads the cookie store, applies the Domain and Path matching rules, and injects matching cookies into the request's Cookie header. The server receives the value it originally set, which is the mechanism that allows it to recognize a returning session. This round-trip structure is what makes cookies a tracking mechanism across multiple page loads and visits.

Technical Components Involved in Cookie Storage

HTTP response and request headers. The Set-Cookie response header and the Cookie request header are the transport layer for cookie data. They are defined in RFC 6265, which specifies parsing rules, attribute semantics, and the domain-matching algorithm browsers must follow.

Browser cookie store. Each browser maintains its own isolated cookie store. The store is partitioned by browser profile, meaning separate profiles on the same machine hold entirely separate cookie databases. The store enforces the attribute rules: expiry, scope, and flag states are not advisory — the browser treats them as binding constraints on read and write operations.

Persistent storage (SQLite database). Persistent cookies land in a structured database file in the browser's profile directory. The file is owned by the browser process. Direct reads of that file by other processes are generally blocked while the browser is running because the database is locked.

In-memory store. Session cookies exist only in the browser process's heap memory. No file write occurs. When the process terminates, the data is gone unless the browser's session-restore feature serializes open tabs — in which case some browsers write session state to a separate recovery file, not to the cookie database.

Third-party cookie context. A cookie set by a resource loaded from a domain different from the top-level page is classified as a third-party cookie. Storage rules are identical, but scope and access are increasingly restricted by browser policy. The SameSite=None; Secure combination is required for a cookie to be sent in cross-site requests, a constraint that affects how advertising and analytics networks maintain state across sites.

Identity cookies. A specific category of persistent cookie is the authentication or identity cookie — a token value that the server uses to associate a request with an authenticated user account. These cookies typically carry a session token or signed identifier rather than raw credentials. Because credential matching and session management are separate mechanisms, the identity cookie does not contain a password; it contains a reference the server maps to an authenticated session record.

Where Cookie Storage Produces Unexpected Results

Private or incognito mode does not remove cookies from the server. In a private browsing session, the browser uses a temporary in-memory cookie store that is discarded when the window closes. No persistent writes occur to the SQLite database. However, any cookie values sent to the server during that session were received and logged by the server in real time. The browser-side deletion after the session has no effect on server-side records already written.

Clearing cookies clears local storage only. When a user clears cookies through the browser's settings interface, the browser deletes entries from its local database and memory store. It does not notify any server, does not revoke session tokens already issued, and does not affect any copy of the cookie value that a server or intermediary may have recorded in a log. A session token that was copied before deletion remains valid until the server expires it independently.

Expiry dates are advisory to the browser, not the server. A cookie's Expires attribute tells the browser when to stop sending and delete the value. It does not instruct the server to invalidate the corresponding session. A server may keep the session record active long after the browser has discarded the cookie, or conversely may expire the session before the cookie's stated date.

Partitioned storage and its limits. Some browsers implement storage partitioning, where the cookie store is keyed by both the cookie's domain and the top-level site that loaded it. This limits cross-site tracking by preventing a third-party domain from reading the same cookie value across different top-level sites. However, partitioning applies only to storage access — it does not affect server-side tracking mechanisms such as IP address logging or fingerprinting, which operate outside the cookie system entirely.

Cookie theft via network interception. If a persistent cookie travels over an unencrypted HTTP connection — possible when the Secure flag is absent — it is visible in plaintext to any party with access to the network path. A copied session cookie can be replayed to the server to impersonate the authenticated session. The HttpOnly flag prevents JavaScript access but offers no protection against network-layer interception.

What an Audit of the Cookie Store Shows — and Does Not Show

A direct inspection of a browser's cookie database reveals the stored name-value pairs, the host and path scope, the expiry timestamps, and the flag states for each entry. This is a complete picture of what the browser currently holds. It shows which domains have set persistent cookies, how long they are configured to last, and whether the HttpOnly and Secure flags were applied.

What the local record does not show is the server-side state those cookies correspond to. A cookie value in the browser database is a reference — typically an opaque token — and the data it points to lives on the server. Inspecting the local file reveals the token, not the session record, account data, or behavioral profile the server has associated with it.

The local record also does not show deleted cookies. Once the browser removes an entry from its database, no forensic trace remains in the cookie store itself. Browser history, network logs, or system-level disk forensics are separate sources that may contain indirect evidence, but the cookie database is a current-state snapshot, not a historical log.

The FTC has noted in its guidance on online tracking that cookies are one of several mechanisms used to build behavioral profiles of consumers, and that the data collected through tracking cookies can be combined with other sources in ways that are not apparent from the cookie value alone. The local storage record cannot reveal how a server has combined cookie-derived identifiers with other data streams — that combination happens entirely outside the browser.

Standards and audits focused on cookie compliance — such as those required under various data protection frameworks — typically examine server-side consent records, cookie categorization disclosures, and data retention policies. These audits are concerned with what data is collected and under what legal basis, not with the technical format of the browser-side storage file. The two layers of the record — local storage and server-side data practice — are evaluated by different instruments and answer different questions. The broader question of how tracking cookies contribute to cross-site profiling involves mechanisms that extend well beyond the storage layer described here.

Cookie storage is a precisely specified, browser-enforced mechanism: a structured database for persistent entries, an in-memory store for session entries, and a set of header attributes that define scope and access rules. The local storage layer is only one half of the system; the server-side session and data infrastructure it communicates with operates independently and is not visible from the browser's own records.

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.