🧹 Security

Clear-Site-Data Header Builder

Build a Clear-Site-Data header (cache, cookies, storage, executionContexts) — useful on logout to wipe origin data.

"cache" — clears the site HTTP cache "cookies" — clears cookies for the origin "storage" — localStorage, IndexedDB, service workers "executionContexts" — reloads browsing contexts "*" — everything (shortcut) Generated header

—

Clearing site data straight from a header

At logout, deleting the session cookie solves half the problem. The other half sits in localStorage, IndexedDB, the service worker cache and the open tabs still holding old state in memory. The Clear-Site-Data header tells the browser to wipe those categories, which is a good deal more reliable than trying to clear each one from JavaScript.

Tick what should be cleared and the page assembles the header. There are four categories: cache, which drops the HTTP cache; cookies, which removes cookies and also HTTP authentication credentials; storage, covering localStorage, sessionStorage, IndexedDB, Cache Storage and service worker registrations; and executionContexts, which reloads the site's open tabs. There is also the wildcard, applying all of them at once.

Two deployment details. The value needs double quotes around each category — without them the header is silently ignored. And the browser only honours it on a response served over HTTPS. The most common use is exactly logout: responding with the header alongside the redirect, making sure the device keeps no residue of the previous session.

Frequently asked questions

Does the clearing affect other sites?

No. The scope is the origin that sent the header, and cookies are cleared for that origin's registrable domain. A header sent by app.example.com touches nothing belonging to another domain.

What is the difference between storage and cache?

Cache is the HTTP cache, what the browser keeps to avoid downloading again. Storage is what the application deliberately wrote: localStorage, sessionStorage, IndexedDB, the service worker Cache Storage and the service worker registrations themselves. At logout, storage is usually the more important of the two.

Can I use it on any endpoint?

You can, and sometimes it is the way out of an incident: a response carrying the wildcard on a URL the user visits clears everything for that origin. Just be careful applying it on a cacheable response or a heavily visited route — clearing the cache on every hit wrecks the site's performance.

Related Tools

📡

Network Error Logging (NEL) Builder

Build NEL and Report-To headers to send network error reports to your own endpoint with sampling fractions.

🔑

TOTP otpauth URI Builder

Builds an otpauth://totp/ URI with issuer, account, base32 secret, digits and period for QR code apps.

📨

DMARC Record Builder

Create a DMARC record with policy (none/quarantine/reject), percentage, ruf/rua mailto and SPF/DKIM alignment.

🛂

CORS Preflight Explainer

Given a CORS request method and headers, shows whether it triggers an OPTIONS preflight and explains why.

🔒

HSTS Header Builder

Builds the Strict-Transport-Security header with max-age, includeSubDomains and preload as selected.

🌐

CORS Config Validator

Validate a CORS configuration (allowed origins or *), checking the format and duplicates. Useful for safely configuring APIs and web servers.