Clear-Site-Data response header

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

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.

// 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.

// 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.

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.

Field notes

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, 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 (w3.org)
• Clear-Site-Data (developer.mozilla.org)
• localStorage and sessionStorage
• CacheStorage and the caches global
• Service worker registration and scope

Specifications

Specification	Status
None.