How Clear-Site-Data Wipes Origin Data in Chromium

This article provides a technical breakdown of how the Clear-Site-Data HTTP response header instructs the Chromium web browser to delete locally stored data for a specific web origin. It covers how Chromium intercepts the header in the network stack, parses the server's directives, and utilizes internal browser components to securely purge cookies, DOM storage, and cached files before completing a network request.

The Header and Security Requirements

The Clear-Site-Data header is sent by a web server—typically during a logout or account deletion flow—to ensure sensitive user data is removed from the client device. The header accepts a comma-separated list of directives: "cookies", "storage", "cache", or the wildcard "*" (which clears all three).

For Chromium to execute this header, the request must be delivered over a secure connection (HTTPS) or originate from localhost. If the header is sent over unencrypted HTTP, Chromium ignores it entirely to prevent man-in-the-middle attackers from maliciously wiping user data.

Interception in the Chromium Network Stack

When a server responds with Clear-Site-Data, Chromium does not immediately render the page. Instead, the browser's network stack intercepts the header.

During a navigation or resource fetch, Chromium's ClearSiteDataHandler detects the header and pauses the response. It parses the string to identify which directives are present and extracts the exact origin (the combination of scheme, hostname, and port) of the request. Before the browser is allowed to process the body of the response or follow a redirect, it delegates the deletion tasks to an internal component called the BrowsingDataRemover.

Wiping Cookies

When the "cookies" directive is present, Chromium targets all cookie data associated with the origin's registered domain.

The BrowsingDataRemover communicates with the NetworkContext and the CookieManager inside the Network Service. It executes a deletion task that strips away:

  • Standard HTTP and HTTPS cookies for that origin.
  • HttpOnly cookies that are normally inaccessible via JavaScript.
  • TLS Channel IDs and HTTP authentication cache entries linked to the origin.

Because cookies can be scoped to subdomains, Chromium wipes cookies across the entire eTLD+1 (effective top-level domain plus one label) associated with the origin, ensuring no residual session identifiers remain.

Wiping Storage

When the "storage" directive is received, Chromium targets the StoragePartition—the internal boundary that manages all client-side storage APIs. Chromium uses its QuotaManager and specific storage contexts to systematically wipe all local data strictly tied to the requesting origin.

This triggers the immediate deletion of:

  • Web Storage: Both localStorage and sessionStorage data structures are emptied.
  • IndexedDB: All databases, object stores, and blobs created by the origin are deleted from the disk.
  • Service Workers: Active Service Workers for the origin are unregistered, and their associated CacheStorage (offline caches managed by the worker) is purged.
  • Additional APIs: Data stored via the FileSystem API, WebSQL (if enabled), and Shared Storage is completely erased.

Unlike cookies, storage is strictly bound to the exact origin. Subdomains are not affected unless they explicitly send their own Clear-Site-Data headers.

Wiping Cache

When the "cache" directive is used, Chromium instructs the NetworkContext to interact with the underlying HTTP disk cache.

Historically, clearing the cache for a single origin was resource-intensive because Chromium had to iterate through the entire cache index to find matching URLs. In modern versions of Chromium, the HTTP cache is partitioned by the top-level site and the frame origin. Chromium leverages this partitioning to locate and evict all cached network responses (such as stylesheets, scripts, and media files) where the origin matches the header's source. In addition to the main HTTP cache, Chromium also clears the renderer process's in-memory cache for that origin.

Synchronization and Completion

A critical feature of Chromium's implementation is execution synchronization. Deleting files from an SSD or updating SQLite databases (which back cookies and IndexedDB) is an asynchronous process.

To prevent race conditions—such as a login page loading and setting a new cookie before the old cookie deletion task finishes—Chromium blocks the network response. The ClearSiteDataHandler waits for callback confirmations from the CookieManager, StoragePartition, and HTTP cache backend. Only after all specified data types are confirmed wiped does Chromium unpause the network request, allowing the browser to follow redirects or render the new document in a completely clean state.