Automatic cookie deletion removes a site's cookies and storage as soon as you close its last tab, unless you have allowlisted the site. It cuts tracking because the identifiers advertisers and analytics tools rely on need to persist for months to be useful; deleting them on every visit turns you into a new visitor each time. It does nothing against fingerprinting, so pair it with a tracker blocker.
Why persistence is the tracker's weak point
A tracking identifier is only valuable if it comes back. A cookie that identifies you for a single session tells the tracker nothing it could not already infer from that session. What makes profiles possible is that the cookie set on the first visit is still there on the fiftieth, months later, across every site that embeds the same tracker. Analytics cookies are deliberately long-lived for this reason:
Set-Cookie: _ga=GA1.1.1829403716.1749462000; Domain=.shop.example; Path=/; Max-Age=63072000; SameSite=LaxThat Max-Age is two years in seconds. The value encodes a random client identifier and the timestamp of your first visit. Delete it when you leave and the next visit generates a fresh one, so the tracker's records show two unrelated visitors instead of one returning person. The cookies guide explains the attributes; this guide is about making the deletion happen without thinking about it.
It matters that this is a first-party cookie. Browser tracking protection increasingly blocks or partitions third-party cookies, and the tracking guide describes how identifiers are laundered into first-party storage through link decoration and CNAME cloaking to survive that. Automatic deletion is the protection that reaches the first-party jar, which is why it complements a blocker instead of duplicating it.
Why automatic beats manual
Most people already know they can clear cookies. Almost nobody does it regularly, because the manual action is all-or-nothing: it logs you out of everything, including the sites you want to stay in, and it happens at most occasionally. Automatic deletion changes three things:
- It is per site: closing the last tab of
news.exampledeletes only that site's data. - It is immediate: the identifier lives for minutes rather than months, so cross-session linking is impossible.
- It has an allowlist: your mail provider, bank and the forums you post on stay logged in, and everything else is wiped.
The behaviour is close to using a private window for every site except the handful you allowlist, without the friction of remembering to. A private window offers a weaker version of the same idea, and its protection ends at the same fingerprinting boundary this one does.
What must be deleted
Deleting only cookies is not enough. A tracker script that runs first-party can store the identifier in several places, and a deletion tool that misses any of them achieves nothing:
| Storage | Used for | Cleared by |
|---|---|---|
| Cookies | Session and tracking identifiers, sent with every request | All browser and extension options |
| localStorage | Persistent key-value store; common fallback for identifiers | Extension "clean localStorage" option; browser clear-on-exit |
| IndexedDB | Structured storage, used by some analytics SDKs | Browser site-data clearing; most extensions |
| Cache and ETags | An ETag header can carry an identifier the browser echoes back | Cache clearing; rarely per-site |
| Service workers | Can rehydrate identifiers on the next load | Site-data clearing |
The practical test is to open a site, close it, reopen it and inspect whether any storage survived. Browsers group all of these as "site data", so a tool that clears site data rather than cookies alone is the one to choose.
Setting it up in the browser
Firefox
Firefox can clear everything on exit with exceptions but cannot clear per tab natively. In Settings, Privacy & Security, tick "Delete cookies and site data when Firefox is closed", then use "Manage Exceptions" to add the sites that should keep their data. The exception entry is a site pattern such as https://mail.example. Combined with Total Cookie Protection, which partitions third-party storage per top-level site, this is a strong baseline that needs only an extension for per-tab granularity. Multi-Account Containers are a further option: a site opened in a container has its own cookie jar, so a tracker's cookie set in one container is invisible in another.
Chrome and Edge
Chrome offers "Delete cookies and site data when you close all windows" under Privacy and security, Third-party cookies, and "Sites that can always use cookies" as the allowlist. Note the trigger: all windows, not a tab. If you leave Chrome running for a week, nothing is deleted for a week. Edge has the equivalent under "Clear browsing data on close". Both browsers also let you block third-party cookies outright, which you should do independently; our browser check reports the third-party cookie behaviour it observes.
Safari
Safari has no per-site auto-delete setting. Its Intelligent Tracking Prevention instead caps the lifetime of cookies written by script to seven days, and to 24 hours when the visit arrived through a decorated link, which achieves part of the same effect automatically. You can block all cookies, but that breaks logins; the realistic Safari answer is ITP plus a content blocker.
Setting it up with an extension
Cookie AutoDelete is the long-standing open-source option for Firefox and Chrome. Its model is worth understanding because other tools copy it:
- Enable automatic cleaning and set the delay after tab close (a few seconds is enough; longer delays let a site that reopens keep its session).
- Turn on cleaning of localStorage as well as cookies; it is off by default in some versions.
- Add sites you stay logged into to the whitelist, which is never cleaned.
- Add sites you use in a single session to the greylist, which is kept while the browser runs and cleared on restart.
- Leave everything else unlisted so it is cleaned when its last tab closes.
Our Scan.now extension implements the same allowlist model alongside a tracker blocker, because the two protections need the same permissions and behave better when they share one allowlist: a site you allow to keep cookies is usually one you also trust not to block. Whichever extension you use, audit it first. An extension with permission to read and delete every site's cookies can also read your session tokens, so run it through the extension analyzer before installing and reject anything that declares external endpoints it has no reason to contact. The extension safety guide covers what to look for.
What automatic deletion does not do
Take the limits seriously, because a tool that is oversold gets abandoned.
Fingerprinting is untouched. A tracker that hashes your canvas rendering, fonts and hardware needs no storage at all, and will re-identify the fresh cookie jar on the next visit as the same browser. The fingerprinting guide covers what reduces uniqueness; check your own with the fingerprint uniqueness test. This is the reason deletion is paired with blocking: the blocker stops the fingerprinting script from loading, and deletion handles the identifiers that arrive anyway.
Logged-in tracking is untouched by design. If you allowlist a large platform that also runs an ad network, its identifier persists and any site embedding its widgets can, subject to third-party cookie rules, link your visits. Log out of platforms you do not need to be logged into, or use a container for them.
Tracking within a session is untouched. Everything you do between opening and closing a site is one profile. Deletion breaks the join between sessions, not within one.
Your IP address is unchanged. For a tracker willing to use it as a weak identifier, a home connection with a stable address links sessions for weeks. On its own it carries little weight, but it is one more signal in the mix.
Side effects and how to handle them
- Cookie banners reappear on every visit, because the consent choice was stored in the cookie you deleted. A consent-management filter list in your blocker suppresses most of them.
- Two-factor "remember this device" prompts return each time for sites not on the allowlist. That is correct behaviour; allowlist the site if it is one you trust.
- Shopping carts empty when you close the tab. Greylist the shop for the session.
- Single sign-on across a company's domains may need every domain allowlisted, not just the login server.
None of these are reasons to give up the protection. They are the visible sign that identifiers really are being removed, and each has a one-line fix. The privacy hub sets this layer in context with the others.
