Auto-delete cookies on tab close

TL;DR: CookieVault Guardian auto-deletes cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations the moment you close the last tab on a domain — unless that domain is whitelisted. It is the free, Manifest V3 successor to Cookie AutoDelete, which Chrome disabled in late 2024.

Auto-delete on tab close is the core capability of CookieVault Guardian: it removes every browser-storage record tied to a domain the instant that domain’s last tab closes, except for sites you explicitly whitelist. It is the modern, Manifest V3-native successor to Cookie AutoDelete, the privacy extension Chrome force-disabled in late 2024 as the Manifest V2 sunset reached its final phase¹. Where the original focused on cookies, Guardian rebuilds the per-tab cleanup workflow on current extension APIs and extends the cleanup target list to every storage surface a tracker can hide in.

What it deletes

In short: Six storage surfaces — cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations — each individually toggleable. The point is to clean everything that can hold cross-session tracking state, not just cookies.

A cookie-only cleaner misses most of the modern tracking surface. MDN documents that cookies are one of several client-side storage mechanisms², and a site that wants to re-identify you after you “cleared cookies” can stash state in IndexedDB, Cache Storage, or a Service Worker that simply re-sets the cookie on your next visit. Guardian closes those gaps.

The six surfaces it cleans:

1. Cookies — every cookie for the domain, including HttpOnly cookies the page itself cannot read
2. localStorage — long-lived key-value storage that survives sessions and is invisible to cookie-only cleaners
3. sessionStorage — per-tab storage, cleaned defensively even though it usually clears with the tab
4. IndexedDB — structured per-origin database, a common place for fingerprint and tracking state
5. Cache Storage — the Service Worker cache API, usable as a tracking side channel
6. Service Worker registrations — long-lived background scripts that can wake up to re-set cookies

Each surface has its own on/off toggle. The sensible default is all six enabled; you only narrow the scope if a specific site you cannot whitelist still needs one of them.

How the trigger works

In short: Guardian listens for tab-close events, checks whether any tab is still open on the closing tab’s domain, and only runs cleanup when the last one closes. Whitelisted domains are skipped. The browser cookie API is the official channel for removing cookies.

The trigger is conservative on purpose. Closing one of several tabs on the same site does not wipe the session out from under the others — cleanup waits for the final tab. When that last tab closes and the domain is not whitelisted, Guardian removes the targeted storage through documented browser APIs; cookies specifically are removed through the official cookie API³ rather than any private mechanism, which is part of why the behavior is predictable across browsers.

The detailed migration walk-through, including how to import an existing rule set, lives on the Cookie AutoDelete alternative page.

The whitelist exemption

In short: The whitelist is what keeps auto-delete useful instead of annoying. Add the sites you want to stay logged into; everything else cleans on tab close. Subdomain inheritance and wildcards keep the list short.

Auto-delete is aggressive, which is exactly the privacy win — and exactly why the whitelist matters. Six rules that make the exemption manageable:

• One-click add — click the Guardian toolbar icon on a site and choose “Add to whitelist”
• Subdomain inheritance on by default — one example.com entry covers mail.example.com and the rest
• Wildcards — *.googleapis.com whitelists every Google APIs subdomain at once
• Greylist — a middle ground that keeps cookies for the current session, then cleans or auto-promotes on next close
• Per-storage scope — keep cookies for a site while still cleaning its caches, if you choose
• Local and unlimited in Free — no cap on whitelist entries without paying

A starter whitelist covering most people in five minutes: your primary email, your code host, your work tools, your bank, and your password manager’s web UI. The full deep dive is on the cookie whitelist page.

Free vs Pro

In short: All cleanup, all storage types, and an unlimited local whitelist are free forever. Pro ($4/month or $36/year) adds encrypted cross-device whitelist sync and 30-day cookie history with undo.

Pro is only worth it if you run Guardian on more than one device and want a single shared rule set. Whitelist sync uses the same zero-knowledge crypto described on the encrypted cloud sync page.

How to set it up

1. Install CookieVault Guardian from the download page
2. Pin the toolbar icon for one-click whitelist access
3. Visit each site you want to stay logged into — email, code host, bank, password manager
4. Click the Guardian icon → “Add to whitelist” on each, leaving subdomain inheritance on
5. Open Settings → Storage types and confirm all six surfaces are enabled
6. Verify your whitelist under Settings → Whitelist
7. Browse normally — closing the last tab on a non-whitelisted domain triggers cleanup
8. Greylist one-off sites you want for the session only, so they clean on the next close

For the full walkthrough with edge cases, see the auto-delete on tab close how-to.

See also

• CookieVault Guardian — the extension this feature powers
• Cookie whitelist — the exemption list deep dive
• Cookie AutoDelete alternative — full migration guide and feature matrix
• Auto-delete on tab close how-to — step-by-step setup
• Clear cookies but stay logged in — the whitelist-driven workflow
• Pricing — Free / Pro / Team breakdown