Clear-Site-Data security response

What it does

Clear-Site-Data instructs the browser to clear specific categories of locally-stored data associated with the responding origin — cookies, cache, storage (localStorage, IndexedDB, Service Worker registrations), and even active JavaScript execution contexts. It's a genuinely powerful cleanup mechanism triggered by a single response header, most commonly used on logout endpoints to ensure no lingering session data, cached responses, or client-side state survives after a user signs out.

Without it, a full logout requires the server to individually expire every cookie it set and hope client-side code correctly clears every piece of local/session storage — Clear-Site-Data collapses all of that into one declarative instruction the browser handles reliably.

Syntax

Clear-Site-Data: "<type>"
Clear-Site-Data: "<type1>", "<type2>"
Clear-Site-Data: "*"

Directives:

Each value must be quoted, comma-separated for multiple directives.

How it's used in practice

• Logout endpoints — the primary real-world use case: a logout request responds with Clear-Site-Data: "cookies", "storage", ensuring the session cookie, any client-side auth tokens in storage, and cached authenticated responses are all wiped in one instruction.
• Account deletion/data export completion — after a user deletes their account or an admin forces a session termination, Clear-Site-Data ensures no residual client-side data persists that could be confused with an active session.
• Security incident response — if a site suspects client-side compromise (XSS that may have written malicious data to storage), forcing a Clear-Site-Data: "*" on next response can be part of an incident containment strategy.
• Multi-tab logout consistency — combined with "executionContexts", other open tabs for the same origin get reloaded, ensuring a user who logs out in one tab doesn't have a stale, still-authenticated-looking session visible in another.

Common mistakes and gotchas

Expecting it to clear data for other origins. Clear-Site-Data only affects the origin that sent the response — it cannot clear cookies or storage for a different domain, even a related one, unless that domain's own server sends its own Clear-Site-Data response.

Using "*" when a narrower directive would suffice. Clearing everything (including cache) on every logout can hurt subsequent page-load performance unnecessarily — if you only need to invalidate the session, "cookies" and "storage" alone is usually sufficient without also nuking the HTTP cache.

Assuming it works over plain HTTP. Like many security-sensitive headers, browsers generally only honor Clear-Site-Data on responses delivered over HTTPS — sending it over an insecure connection may be silently ignored.

Not accounting for browser support gaps. While broadly supported in modern browsers, Clear-Site-Data isn't universal across every browser/version — it should be treated as a strong best-effort cleanup mechanism, not a guaranteed one, especially for older or less common browsers. Server-side session invalidation should always be the authoritative source of truth, with Clear-Site-Data as client-side reinforcement.

Real-world examples

Standard logout response:

HTTP/1.1 200 OK
Clear-Site-Data: "cookies", "storage"
Set-Cookie: session=; Max-Age=0

Full security cleanup:

HTTP/1.1 200 OK
Clear-Site-Data: "*"

Clearing only the cache after a deployment issue:

HTTP/1.1 200 OK
Clear-Site-Data: "cache"

FAQ

Does Clear-Site-Data replace the need to expire cookies server-side with Set-Cookie?

No — it's complementary, not a replacement. Always invalidate the session server-side (so the cookie/token is rejected even if a client somehow retains it) in addition to instructing the browser to clear it client-side.

Can Clear-Site-Data clear data for subdomains?

Cookie clearing follows normal cookie scoping rules — if cookies were set with a domain attribute covering subdomains, they'll be cleared accordingly. Storage (localStorage, IndexedDB) is generally scoped per-origin, so a response from app.example.com won't clear storage belonging to api.example.com.

Will Clear-Site-Data log the user out of other open tabs immediately?

Only if you include the "executionContexts" directive, which triggers a reload of open browsing contexts for the origin — without it, other open tabs may still show stale (though no longer server-authenticated) UI state until the user next interacts with them.

Is Clear-Site-Data supported in all browsers?

Support is broad among modern browsers but not universal, and specific directive support can vary — treat it as a strong best-effort client-side cleanup mechanism that reinforces, but doesn't replace, proper server-side session invalidation.

Fun fact

Clear-Site-Data emerged specifically because developers had been solving the "clear everything on logout" problem with increasingly elaborate client-side JavaScript for years — manually iterating over every known storage API, guessing at cookie names and domains, and still frequently missing something. The header formalizes what was essentially a recurring, error-prone pattern into a single declarative browser-native instruction, removing an entire category of "did we actually clear all the user's data" bugs from logout implementations.