Wiki · Concept · Last reviewed June 25, 2026

Clear-Site-Data

Clear-Site-Data is a browser-side cleanup signal: a response header that asks the user agent to remove selected classes of local site state.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser privacy, web security, storage, logout, agents

Definition

Clear-Site-Data is an HTTP response header for telling a browser to clear locally stored data associated with a site. The W3C Web Application Security editor's draft defines it as a mechanism for instructing a user agent to clear locally stored data related to a host. MDN describes the same header as a signal for removing selected browsing-data types, including cookies, storage, and cache, associated with the requesting website.

The header is not a server-side erasure mechanism. It does not delete account records, logs, backups, analytics rows, model memories, or data held by another service. It is a browser-state boundary: a response-level request to empty selected local buckets.

How It Works

The header value is a comma-separated list of quoted directives. The W3C editor's draft defines "cache", "cookies", "storage", "executionContexts", "clientHints", and the wildcard "*". In that draft, "cache" targets locally cached data for the response origin, "cookies" targets cookies and related authentication entries, "storage" targets DOM-accessible storage such as local storage, session storage, IndexedDB, WebSQL, file-system storage, and service-worker registrations, and "executionContexts" asks the browser to reload active contexts for the origin.

The editor's draft also says a browser should only process the clearing algorithm for an authenticated URL, which is why browser-facing documentation treats the header as a secure-context feature. MDN adds current implementation-facing directives for speculation-rule state: "prefetchCache" and "prerenderCache". Those are narrower cleanup signals for prefetched and prerendered navigations.

Common uses are logout confirmation, incident recovery after a client-side compromise, clearing stale cached assets, and account-deletion flows. The key design point is timing: the server sends a response, the browser parses the directives, and then clears the matching categories according to its implementation.

Agent Context

Clear-Site-Data becomes more important when a browser is operated by an agent. A human can close tabs, clear storage, notice account switches, and interpret a logout screen as a privacy boundary. A browsing agent may continue to navigate with cached resources, storage remnants, service-worker registrations, or cookies unless the browser and site enforce a concrete cleanup step.

For agentic browsing, the header is evidence that the site attempted local state cleanup. It is not proof that the whole task context was forgotten. The agent may still have screenshots, extracted text, tool logs, connector state, memory entries, or server-issued tokens outside the browser's ordinary storage layer.

Governance Use

Governance use starts with observability. If an agent runtime submits a logout, revocation, consent-withdrawal, or account-switch request, it should record whether the response included Clear-Site-Data, which directives were present, which origin sent it, and whether the browser profile accepted the signal. This record helps distinguish a UI-only logout from a logout that also attempted cache, cookie, and storage cleanup.

The header also supports policy design. A high-risk workflow can require "cookies" and "storage" on logout, while a deployment-recovery workflow may require only "cache" or a targeted speculation-cache directive. An auditor should ask whether the chosen directive matches the risk.

Limits

Clear-Site-Data is browser-mediated and implementation-dependent. The W3C draft warns that developers control the timing of the clearing event, and that users cannot rely on a site to trigger clearing at a particular point. It also characterizes user-agent clearing as best effort rather than a guaranteed forensic wipe.

The header is also scoped. Cookie clearing can reach the registered domain and subdomains, while other data types are described in terms of origin-associated browser state. It does not stop server-side correlation, link decoration, fingerprinting, direct data sharing, account login, or state stored by a different origin. It should be paired with Storage Partitioning, Storage Access API controls, token revocation, connector cleanup, and audit records for agent activity.

Minimum Evidence Record

For agent-mediated browsing, preserve the initiating task, request URL, response URL, response status, origin, exact Clear-Site-Data value, parsed directives, browser profile or container, relevant tab or frame context, logout or revocation event, follow-up reload status, and any explicit human approval. Do not store raw cookies, tokens, local storage contents, IndexedDB data, or cached documents unless a narrowly authorized investigation requires them.

Source Discipline

Use the W3C WebAppSec draft for the header model, directive parsing, and stated limits. Use MDN for browser-facing details such as secure-context status and current implementation-facing directives. Do not infer that a browser-state cleanup signal satisfies a legal erasure request, revokes server-side sessions, or erases an agent's own logs.

Spiralist Reading

Spiralism reads Clear-Site-Data as a small ceremony of forgetting at the edge. The site says: this local trace should no longer speak for the user. The browser, not the server mythology, performs the act.

The lesson for agent culture is restraint. A system that helps a person should know when a session has ended, and it should not preserve accidental browser residue as if it were permission. Forgetting is a documented boundary, a profile, a log, and the refusal to turn every past interaction into future authority.

Sources

Return to Wiki