# Clear-Site-Data response header

> The Clear-Site-Data response header: quoted directives, what cache, cookies, and storage remove, per-browser support, and how to send it on sign-out.

`Clear-Site-Data` is an HTTP response header that tells the browser to delete stored data for the
response's origin: cookies, the HTTP cache, DOM storage and service worker registrations, or
every type at once. It is the server-side counterpart of a user clicking "Clear site data", and
the only standard way to remove another tab's `localStorage` and IndexedDB during sign-out.

## Syntax

```http
Clear-Site-Data: "cache"
Clear-Site-Data: "cache", "cookies"
Clear-Site-Data: "cookies", "storage", "executionContexts"
Clear-Site-Data: "*"
```

Each directive is a quoted string; `Clear-Site-Data: cookies` without quotes is invalid and
ignored. The header is honoured only on responses delivered over HTTPS (secure context) and is
processed before the response body is handed to the page, so a `storage` directive on a page
response wipes storage before that page's scripts run.

## Members

| Directive | Removes | Support (BCD `http.headers.Clear-Site-Data`) |
|---|---|---|
| `"cache"` | The HTTP cache for the origin and, depending on the engine, prerendered pages, bfcache entries, and script caches. | Chrome 61, Firefox 63, Safari 17. In Chrome 127+ cached responses may still be served until the tab reloads (crbug 364634040). |
| `"cookies"` | Every cookie for the registrable domain of the response URL, including subdomains, plus HTTP authentication credentials. | Chrome 61, Firefox 63, Safari 17 |
| `"storage"` | `localStorage`, `sessionStorage`, IndexedDB, Cache Storage, OPFS, and service worker registrations for the origin. | Chrome 61, Firefox 63, Safari 17 |
| `"executionContexts"` | Reloads every browsing context for the origin after clearing. | Firefox 63 to 68 and Safari 17 to 18.3 only; not implemented in Chromium. Treat it as unavailable. |
| `"prefetchCache"`, `"prerenderCache"` | Speculation Rules prefetches and prerenders whose referrer is the origin. | Chrome 138+. Not standardised; Firefox and Safari ignore them. |
| `"clientHints"` | Stored `Accept-CH` client hint preferences. Also cleared by `"cache"`, `"cookies"`, and `"*"`. | Chrome 117+ |
| `"*"` | Every type the engine supports, including types added later. | Chrome 61, Firefox 63, Safari 17 |

The `"cookies"` directive is domain-wide: a header from `app.example.com` removes cookies for
`example.com` and `www.example.com` too.

## Support across engines

The header itself is honoured by Chrome 61, Firefox 63, and Safari 17 (BCD
`http.headers.Clear-Site-Data`), and MDN lists it as Baseline since September 2023. Support is
per directive, as the Members table shows: the three core directives are universal, the
speculation-cache and client-hint directives are Chromium-only, and `"executionContexts"` has no
shipping implementation. The header is ignored on plain HTTP and in Android WebView.

## Exceptions

None.

## Examples

The header is set by the server, so the examples are server code, with one client-side fallback
for engines that do not honour it.

### Clearing state on sign-out

Send the header on the response that confirms the session ended, not on the page that offers
the sign-out button; the browser acts on it the moment the response headers arrive.

```js
// Node.js / Express
app.post('/logout', (req, res) => {
  req.session.destroy(() => {
    res.set('Clear-Site-Data', '"cache", "cookies", "storage"');
    res.status(204).end();
  });
});
```

A `204` keeps the response small and avoids a redirect, because a redirect response carrying
the header clears data before the redirected request is sent, which also drops the session
cookie that the redirect target might have needed.

### Clearing only the service worker and its caches after a bad deploy

`"storage"` removes the service worker registration together with Cache Storage, which is the
fastest recovery when a shipped worker serves a broken shell. Serve the header once from a URL
every client is known to request, such as the manifest.

```js
// Cloudflare Worker
export default {
  async fetch(request) {
    const response = await fetch(request);
    if (new URL(request.url).pathname === '/manifest.webmanifest') {
      const headers = new Headers(response.headers);
      headers.set('Clear-Site-Data', '"storage"');
      return new Response(response.body, { status: response.status, headers });
    }
    return response;
  },
};
```

Remove the header again after the fix has propagated: while it is present, every manifest fetch
unregisters the worker and the app behaves as a plain website.

### Falling back when the header is not honoured

No script-visible signal confirms that the browser processed the header. A sign-out handler
therefore also clears what it can from script and unregisters service workers itself; on an
engine that honoured the header this is redundant, and on one that did not it is the only
cleanup.

```js
async function confirmLogout() {
  const res = await fetch('/logout', { method: 'POST' });
  if (!res.ok) return false;
  localStorage.clear();
  sessionStorage.clear();
  if (!('serviceWorker' in navigator)) {
    return true; // no service worker support: Web Storage was all there was to clear
  }
  const regs = await navigator.serviceWorker.getRegistrations();
  await Promise.all(regs.map((reg) => reg.unregister()));
  return true;
}
```

`document.cookie` cannot remove `HttpOnly` cookies, so the header, or an expiring `Set-Cookie`
from the server, remains the only way to drop a session cookie.

:::observed
Chromium's `"cache"` and `"*"` directives carry two open bugs recorded in BCD: the response can
hang for several seconds while the cache is purged (crbug 40233601), and from Chrome 127 some
requests continue to be answered from the HTTP cache until the tab is reloaded or the page is
opened in a new tab (crbug 364634040) ([Clear-Site-Data.json](https://github.com/mdn/browser-compat-data/blob/main/http/headers/Clear-Site-Data.json),
github.com). A sign-out response that clears only `"cookies", "storage"` avoids both, which is the
combination to prefer unless cached HTML must go.
:::

## See also

- [Clear Site Data: the header](https://w3c.github.io/webappsec-clear-site-data/#header) (w3.org)
- [Clear-Site-Data](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Clear-Site-Data) (developer.mozilla.org)
- [localStorage and sessionStorage](/reference/storage/localstorage/)
- [CacheStorage and the caches global](/reference/storage/cache-storage/)
- [Service worker registration and scope](/reference/service-worker/registration-scope/)