Clearing site data: the Clear-Site-Data response header

In one line: “The HTTP Clear-Site-Data response header sends a signal to the client that it should remove all browsing data of certain types (cookies, storage, cache) associated with the requesting website,” per MDN, giving a server explicit control over data a browser has stored for its origin.

Syntax and the quoted-string requirement

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

MDN is explicit about formatting: “All directives must comply with the quoted-string grammar. A directive that does not include the double quotes is invalid” — Clear-Site-Data: cookies (unquoted) is rejected.

Directives

Per MDN’s directive descriptions:

• "cache" — the client should remove locally cached data (the browser cache), and “depending on the browser, this might also clear out things like pre-rendered pages, backwards-forwards cache, script caches, WebGL shader caches, or address bar suggestions.”
• "cookies" — removes “all cookies for the origin of the response URL,” including HTTP authentication credentials, and “this affects the entire registered domain, including subdomains” (example.com and stage.example.com alike).
• "storage" — removes “all DOM storage for the origin of the response URL” (localStorage, sessionStorage, IndexedDB, service worker registrations, and other origin-scoped storage).
• "executionContexts" — signals the client “should reload all browsing contexts for the origin of the response” (Location.reload).
• "prefetchCache" / "prerenderCache" — clear speculation-rules prefetches or prerenders “scoped to the referrer origin.”
• "clientHints" — removes stored client hints, but is “only needed when none of” cache, cookies, or * are also specified, since those already clear client hints as a side effect.
• "*" — clears every data type; per MDN, “if more data types are added in future versions of this header, they will also be covered by it.”

Clearing data on sign-out

MDN’s example sends the header from the response that confirms a successful logout:

Clear-Site-Data: "cache", "cookies", "storage", "executionContexts", "prefetchCache", "prerenderCache"

Serve that header from https://example.com/logout (or equivalent) once the server has confirmed the session ended — not preemptively, since the browser acts on it immediately.

There is no runtime support check

Clear-Site-Data is a response header rather than a JavaScript-exposed API. Neither MDN’s description of the header nor the W3C specification defines a script-readable signal for whether the browser processed a directive. Treat res.headers.has("Clear-Site-Data") and window.isSecureContext as diagnostics only: the header check reflects what the response contained, and window.isSecureContext reflects the one hard precondition MDN documents for the browser to act at all (secure context) — but neither one, alone or combined, confirms the browser actually processed the directive. Do not name that combination supported, and do not gate a cleanup step on it.

Because no such check exists, treat the header as a server-side enhancement and, after a successful logout, also attempt the client-side cleanup below, without gating it on either check. This snippet clears localStorage and sessionStorage, and iterates over document.cookie attempting to expire each entry it finds — an attempt, not a guarantee, since the W3C spec’s own "cookies" clearing algorithm works by enumerating matching cookies directly in the browser’s cookie store rather than expiring them one at a time from script. Per MDN, the header’s own "storage" directive also covers more ground than this snippet’s localStorage/sessionStorage clearing — it additionally removes IndexedDB and service worker registrations for the origin:

async function confirmLogout() {
  const res = await fetch("/logout", { method: "POST" });
  if (!res.ok) return false;
  const secureContextWithHeader = window.isSecureContext && res.headers.has("Clear-Site-Data");
  if (!secureContextWithHeader) {
    // Diagnostic only, per MDN: outside a secure context (HTTPS) the
    // browser never processes Clear-Site-Data, and a response without the
    // header could not have triggered it either — but neither this check
    // nor its opposite proves whether the browser actually ran it, so it
    // is not a gate for the cleanup below.
    console.warn("Clear-Site-Data may not have taken effect for this response.");
  }
  // Neither MDN nor the W3C spec documents a way to observe from script
  // whether the browser actually acted on Clear-Site-Data, so attempt
  // this script-visible cleanup too, instead of gating it on the
  // diagnostic check above. Note that if this response's headers also
  // included "executionContexts", the resulting page reload could run
  // before this code below gets a chance to:
  localStorage.clear();
  sessionStorage.clear();
  document.cookie.split(";").forEach((c) => {
    document.cookie = c.replace(/^ +/, "").replace(/=.*/, "=;expires=" + new Date(0).toUTCString());
  });
  return true;
}

Where it is supported

MDN’s Baseline status for this header is “Widely available — This feature is well established and works across many devices and browser versions. It’s been available across browsers since September 2023.” MDN also states the header “is available only in secure contexts (HTTPS), in some or all supporting browsers.”

Practical checklist

• Quote every directive — MDN states an unquoted directive like Clear-Site-Data: cookies is invalid per the header’s quoted-string grammar.
• Serve the header over HTTPS: MDN documents it as available “only in secure contexts.”
• Send it from the response that confirms logout succeeded, not earlier — MDN’s example places it on the /logout confirmation response.
• Remember "cookies" clears the entire registered domain including subdomains, per MDN — not just the exact host that sent the response.
• Skip "clientHints" when "cache", "cookies", or "*" are already present — MDN notes those directives already clear client hints as a side effect.
• Do not treat res.headers.has("Clear-Site-Data"), window.isSecureContext, or any combination of the two as a “supported” check — neither MDN nor the W3C spec documents a way to observe from script whether the browser actually processed the header. Attempt the script-side cleanup after every successful logout instead of gating it on either check.
• Do not assume a localStorage/sessionStorage/document.cookie cleanup snippet reaches everything the "storage" directive clears — per MDN, "storage" also removes IndexedDB and service worker registrations for the origin, which such a script-visible snippet does not touch.

Cross-references

• Storage persistence
• Storage Access API