Clear-Site-Data: Wipe Cookies and Storage Remotely

The Clear-Site-Data HTTP response header allows web servers to remotely instruct a client’s browser to purge stored browsing data associated with the hosting origin. By returning this header in an HTTP response—typically during user logout, permission changes, or security incident remediations—a web application can systematically remove cookies, DOM storage (such as localStorage and sessionStorage), IndexedDB databases, service workers, and network caches without relying on complex client-side JavaScript cleanup scripts.

How the Header Works

When a browser makes an HTTP request over a secure connection (HTTPS), the server can include the Clear-Site-Data header in its response. Upon receiving and parsing this header, the browser intercepts the instruction and executes a localized cleanup routine across its internal storage systems for the requesting origin (the combination of protocol, domain, and port).

Because the deletion happens at the browser engine level, it bypasses many of the limitations that client-side JavaScript faces, such as the inability of JavaScript to delete HttpOnly cookies or cleanly terminate running service workers.

Syntax and Supported Directives

The Clear-Site-Data header accepts one or more quoted string directives separated by commas, allowing granular control over which storage layers are cleared:

Clear-Site-Data: "cookies", "storage", "cache"

The available directives include:

Wiping Client-Side Storage vs. Cookies

1. Cookies

Traditionally, a server clears cookies by sending multiple Set-Cookie headers with past expiration dates for each individual cookie. This approach is prone to failure if cookie paths or domains are mismatched. The "cookies" directive in Clear-Site-Data replaces this process by instructing the browser to instantly drop all cookies tied to the exact origin, regardless of their path, flags, or creation method.

2. JavaScript Storage (localStorage, sessionStorage, IndexedDB)

Client-side storage mechanisms are normally managed directly by scripts using APIs like localStorage.clear() or indexedDB.deleteDatabase(). However, if an application needs to enforce a logout from the server side, JavaScript might not execute if the page has already redirected. The "storage" directive forces the browser engine to clear all storage APIs tied to the origin before rendering the new response or processing subsequent requests.

Practical Implementation Example

A common scenario is a user logout endpoint (e.g., POST /api/logout). When processing the logout, the backend invalidates the session server-side and sends the cleanup header:

HTTP/1.1 200 OK
Content-Type: application/json
Clear-Site-Data: "cookies", "storage"

{"status": "logged_out"}

Once the browser reads this response, all session identifiers, local tokens, cached application state, and IndexedDB records tied to that website are removed from the client machine.

Key Considerations and Limitations