# CookieVault > CookieVault is a privacy-first suite of two Manifest V3 browser extensions: > **Editor** (cookie manager / EditThisCookie alternative) and **Guardian** > (auto-delete cookies on tab close / Cookie AutoDelete replacement). > Free, MIT-licensed open-source core; optional Pro tier with end-to-end > encrypted sync, multi-account profiles, history, and CSV/HAR export. ## Products - [CookieVault Editor](https://cookievault.net/en/editor/): Full cookie CRUD, profiles, sync. - [CookieVault Guardian](https://cookievault.net/en/guardian/): Auto-delete cookies on tab close. - [CookieVault Team](https://cookievault.net/en/team/): Shared whitelists, SSO, audit log. ## Migration guides - [From EditThisCookie](https://cookievault.net/en/alternatives/editthiscookie/): Step-by-step import. - [From Cookie AutoDelete](https://cookievault.net/en/alternatives/cookie-autodelete/) - [From Cookie-Editor by Moustachauve](https://cookievault.net/en/alternatives/cookie-editor/) - [From Cookiebro](https://cookievault.net/en/alternatives/cookiebro/) ## How-tos - [Delete cookies in Chrome](https://cookievault.net/en/how-to/delete-cookies-chrome/) - [Clear cookies but stay logged in](https://cookievault.net/en/how-to/clear-cookies-but-stay-logged-in/) - [Edit cookies in Chrome](https://cookievault.net/en/how-to/edit-cookies-chrome/) - [Export cookies as JSON](https://cookievault.net/en/how-to/export-cookies-json/) - [Auto-delete cookies on tab close](https://cookievault.net/en/how-to/auto-delete-on-tab-close/) - [Whitelist cookies](https://cookievault.net/en/how-to/whitelist-cookies/) ## Concepts - [What is a cookie?](https://cookievault.net/en/concepts/what-is-a-cookie/) ## Pricing & Trust - [Pricing](https://cookievault.net/en/pricing/): Free, Pro $3.99/mo or $29/yr, Team $8/seat/mo. - [Security architecture](https://cookievault.net/en/security/): AES-256-GCM + PBKDF2-SHA-256 (Web Crypto API) E2EE design. - [No-sale pledge](https://cookievault.net/en/no-sale-pledge/) - [Privacy policy](https://cookievault.net/en/privacy/) - [Open source (MIT)](https://cookievault.net/en/open-source/) ## Updates - [Changelog](https://cookievault.net/en/changelog/) - [Blog](https://cookievault.net/en/blog/) ## Repository - [GitHub org](https://github.com/extensionsly) - [Editor extension](https://github.com/extensionsly/cookievault-editor) - [Guardian extension](https://github.com/extensionsly/cookievault-guardian) --- ## Full content ### alternatives/en/cookie-autodelete.md --- title: 'Cookie AutoDelete alternative — Manifest V3 replacement' slug: cookie-autodelete description: 'CookieVault Guardian is the open-source Cookie AutoDelete alternative — Manifest V3, full whitelist parity, plus localStorage / IndexedDB / Cache cleanup CAD never had. Free, MIT.' type: alternative locale: en cluster: migration author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookie autodelete alternative secondaryKeywords: - cookie autodelete replacement chrome - cookie autodelete manifest v3 - cookie autodelete disabled - cookie autodelete chrome stopped working - auto delete cookies extension chrome intent: commercial funnel: bofu schemaType: - SoftwareApplication - FAQPage - HowTo geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true howToSteps: - name: Export your Cookie AutoDelete whitelist text: While Cookie AutoDelete is still installed (on Firefox, or on a Chromium browser that has not yet force-disabled it), open its Settings page and choose "Export → Whitelist + Greylist". Save the JSON to a location you can find again. - name: Install CookieVault Guardian text: Open the CookieVault download page, download the verified Guardian ZIP, and follow the manual installation steps. Browser-store listings are not yet available. - name: Import the whitelist text: Click the new Guardian toolbar icon, open Settings (gear), and choose "Import → Cookie AutoDelete JSON". Select the file from step 1. - name: Verify domains appear in the whitelist text: Switch to the Whitelist tab and confirm every domain you had in Cookie AutoDelete is now in Guardian. Subdomain inheritance defaults to on, so a single `example.com` entry covers `mail.example.com` automatically. - name: Test the cleanup workflow on a real site text: Open a non-whitelisted site, browse for a minute, then close the tab. Reopen the same site — you should be logged out and any localStorage / IndexedDB data should be gone. If a site you expected to stay logged in does not, add it to the whitelist. - name: Tune the cleanup scope text: In Settings → Cleanup Targets, enable or disable each storage type independently — cookies (always on), localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations. Defaults are sensible; only narrow the scope if a critical site breaks. - name: Enable encrypted whitelist sync (optional) text: If you want the same whitelist across multiple devices, open Settings → Sync, create an account, and choose a passphrase. The passphrase derives the encryption key client-side; the Guardian sync server stores only opaque ciphertext. - name: Uninstall Cookie AutoDelete text: On any browser where Cookie AutoDelete is still installed (typically Firefox at this point), go to the extensions page and remove it. Keep the exported JSON for at least 30 days in case you need to roll back. faq: - q: Why did Cookie AutoDelete stop working in Chrome? a: Chrome disabled all Manifest V2 extensions in the stable channel as part of its MV2 sunset, which began rolling out in June 2024 and completed in early 2025. Cookie AutoDelete relied on a persistent MV2 background page to track tab-close lifecycle and was not rewritten for Manifest V3, so it was caught in the disablement wave along with thousands of other privacy extensions. - q: Does Cookie AutoDelete still work in Firefox? a: Yes. Firefox kept Manifest V2 support and the maintained Cookie AutoDelete build on Firefox Add-ons continues to install and function. If you only use Firefox and your workflow is stable, there is no urgency to migrate. CookieVault Guardian on Firefox primarily helps users who want the same whitelist synced across Firefox + Chrome / Edge / Brave. - q: Will Guardian import my Cookie AutoDelete JSON without losing entries? a: Yes. The Cookie AutoDelete JSON format includes whitelist, greylist, expression matching mode (wildcard / regex / domain), and per-container associations on Firefox. Guardian's importer parses all of these and rehydrates them into the Guardian rule store. If you hit a parse error, file an issue with the JSON attached (after scrubbing any sensitive domain names). - q: What does Guardian clean beyond cookies? a: localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations — all on the same per-domain whitelist as cookies. Cookie AutoDelete only cleaned cookies (and partial localStorage in later versions); Guardian extends the same tab-close model to every browser-storage API that can hold tracking state. - q: What sites will break if Guardian cleans IndexedDB / localStorage? a: Any site that stores meaningful state client-side without backing it up to a server. Common cases — drafts in online editors, PWA offline caches, JS framework state caches, some video player resume positions. If a site breaks after a tab close, add it to the whitelist. The greylist is useful for sites you want to use this session but auto-clean next time. - q: Is the free tier limited? a: The core cleanup workflow is included. The Free tier covers the entire local cleanup workflow — up to 10 local Guardian rules, every storage type, wildcard patterns, greylist. Pro adds end-to-end encrypted cross-device whitelist sync and 90-day cookie history. - q: Is CookieVault Guardian the same extension as CookieVault Editor? a: No, they are two separate extensions you can install independently or together. Editor is the EditThisCookie-style cookie manager (view / edit / export individual cookies). Guardian is the Cookie AutoDelete-style tab-close cleaner. Most users install both; if you only need one, pick the one that matches your workflow. - q: Is there a way to undo Guardian's cleanup if I close a tab by accident? a: Cookies, localStorage, sessionStorage, and IndexedDB cleanup is irreversible the moment Guardian runs it — once the data leaves the browser's storage, the browser cannot recover it. For high-value sites (banking, work tools), the right protection is to whitelist them. Guardian's Pro tier additionally keeps a 90-day cookie history (cookies only, not the other storage types) that lets you restore individual cookies one click at a time. --- # Cookie AutoDelete alternative > **TL;DR**: CookieVault Guardian is the open-source, Manifest V3-native Cookie AutoDelete alternative. It restores the tab-close auto-cleanup workflow on every Chromium browser plus Firefox, matches the whitelist / greylist UX, and extends cleanup to localStorage, IndexedDB, and Cache Storage — areas Cookie AutoDelete never covered. CookieVault Guardian is a free, MIT-licensed browser extension that provides a Manifest V3 replacement for Cookie AutoDelete, the long-running privacy extension that Chrome force-disabled in late 2024 as the Manifest V2 sunset reached its final phase. Guardian rebuilds the per-tab cleanup workflow on modern extension APIs and expands the cleanup target list from cookies-only to every browser-storage API that can hold tracking state. ## What happened to Cookie AutoDelete > **In short**: Cookie AutoDelete was the privacy community's default tab-close cookie cleaner on Chrome and Firefox for years, with a reported peak install base of around 280,000 Chrome weekly active users[^1]. Chrome's Manifest V2 sunset disabled all MV2 extensions in the stable channel between June 2024 and early 2025[^2]; Cookie AutoDelete was caught in this wave because its core architecture depended on persistent MV2 background pages and was never rewritten for MV3. The GitHub repository[^3] remains public under the MIT license; the Firefox Add-ons listing still works because Firefox kept MV2 support. Cookie AutoDelete was created by Kenny Do (mrdokenny on GitHub) and grew into a community-maintained project under the `Cookie-AutoDelete` GitHub organization[^3]. It served users who wanted Firefox's "Delete cookies and site data when Firefox is closed" behavior, but on a per-tab rather than per-browser-session basis — closing the last tab on a domain triggered cleanup for that domain, independent of whether the browser kept running. The extension's core mechanism — listening to `chrome.tabs.onRemoved` from a persistent background page and reconciling the open-tab set against the cookie store — depended on APIs that Manifest V3 changed fundamentally. MV3 replaces persistent background pages with ephemeral service workers and requires extensions to use declarative APIs in many places where MV2 allowed imperative ones. Rewriting Cookie AutoDelete for MV3 would have required substantial reengineering of the tab-lifecycle tracking logic, and the maintainers publicly indicated[^4] that this rewrite was not on their roadmap. When Chrome stable's MV2 disablement reached general rollout in late 2024, Cookie AutoDelete stopped functioning for an estimated 280,000+ weekly active Chrome users overnight, along with thousands of other unmigrated MV2 extensions. ## Why you need a replacement now > **In short**: If you used Cookie AutoDelete on Chrome / Edge / Brave / Opera / Vivaldi / Arc, you have no in-store update path — the extension is permanently disabled. If you used it on Firefox, you can keep using it, but you lose the ability to share a whitelist across browsers. Either way, the storage scope (cookies + partial localStorage) is narrower than modern tracking practices warrant. Three reasons a 2025 Cookie AutoDelete user should evaluate a migration: 1. **Chrome browsers no longer load it.** This is hard, not soft — Chrome's MV2 disablement in the stable channel is policy, not a bug, and the disablement is not reversible. Users on Chrome / Edge (Chromium) / Brave / Opera / Vivaldi / Arc are left without auto-cleanup unless they install something else. 2. **Storage scope has moved beyond cookies.** Tracking and session state today routinely live in localStorage, IndexedDB, and Cache Storage — none of which Cookie AutoDelete cleans comprehensively. Cleaning only cookies on tab close is increasingly a partial defense, because a tracker can rehydrate user identity from any of those side channels. 3. **The maintainer track is wound down.** Even on Firefox, the original maintainers have indicated[^4] that active development on Cookie AutoDelete has slowed. The repository is still there, still MIT-licensed, but updates are infrequent. If you only use Firefox and your current whitelist works for you, there is no urgency — Cookie AutoDelete on Firefox is not going away tomorrow. But for everyone else, and for users who want unified cleanup across all storage types, a Manifest V3-native replacement is the better posture. ## What CookieVault Guardian adds beyond Cookie AutoDelete > **In short**: Guardian is a strict superset of Cookie AutoDelete's feature surface. Everything Cookie AutoDelete did, Guardian does; the additions are expanded storage cleanup (localStorage, sessionStorage, IndexedDB, Cache Storage, Service Worker registrations), cross-device whitelist sync (Pro), and modern Manifest V3 compatibility. Guardian's design starts from "Cookie AutoDelete's UX, but on MV3" and adds three categories of improvements: - **Storage scope.** Cookie AutoDelete cleaned cookies and, in later versions, partial localStorage. Guardian cleans cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations — every browser-storage surface that can hold cross-session state. Each storage type is individually toggleable in settings. - **Cross-device whitelist sync (Pro).** Cookie AutoDelete's whitelist lives locally per browser profile. Guardian's Pro tier syncs the whitelist across all your devices via an end-to-end encrypted channel — the same domain rules apply on your laptop, work machine, and home desktop without manual re-entry. - **Manifest V3 native.** No persistent background pages. Service-worker-based architecture. Compatible with the next decade of Chrome extension API evolution rather than the previous one. Everything else — whitelist UX, greylist (delete on next close then auto-promote), wildcard matching, Firefox container support, manual "Clean now" button — is preserved at parity. ## What Guardian does NOT do that Cookie AutoDelete did Honesty matters: Guardian is not strictly better in every dimension. Three areas where Cookie AutoDelete had a small edge: - **Smaller install footprint.** Cookie AutoDelete packs to ~150 KB; Guardian packs to ~480 KB (sync client + crypto library inflates the bundle). - **Longer Firefox track record.** Cookie AutoDelete has been on Firefox Add-ons since 2017 with a multi-year stability record. Guardian is newer there. - **Pure local-only mode**: Cookie AutoDelete never asked you to create an account. Guardian's local-only mode is identical, but the existence of a Pro / sync tier may feel like overhead even when you do not use it. If those points outweigh the storage-scope and sync benefits for your workflow, staying on Cookie AutoDelete (Firefox) is reasonable. ## CookieVault Guardian vs Cookie AutoDelete vs alternatives | Criterion | CookieVault Guardian | Cookie AutoDelete | Self-Destructing Cookies (legacy Firefox) | | --------------------------------------------- | -------------------- | ----------------- | ----------------------------------------- | | License | MIT (open source) | MIT (open source) | MIT (open source) | | Manifest version | V3 | V2 (deprecated) | XUL (Firefox legacy) | | Active maintenance | Yes | Slowed[^4] | Discontinued (2017) | | Chrome / Edge / Brave / Opera / Vivaldi / Arc | Yes | No (disabled) | No | | Firefox | Yes (MV3) | Yes | No (XUL removed) | | Whitelist / greylist | Yes | Yes | Yes | | Wildcard patterns | Yes | Yes | Limited | | Firefox container support | Yes | Yes | N/A | | Cleans cookies | Yes | Yes | Yes | | Cleans localStorage | Yes | Partial | No | | Cleans sessionStorage | Yes | No | No | | Cleans IndexedDB | Yes | No | No | | Cleans Cache Storage | Yes | No | No | | Cleans Service Worker registrations | Yes | No | No | | Cross-device whitelist sync | Yes (Pro) | No | No | | Install size | ~480 KB | ~150 KB | N/A | The honest read: for Firefox-only users with a stable workflow, Cookie AutoDelete remains a reasonable choice. For everyone else — Chromium-browser users, cross-browser users, or anyone who wants cleanup beyond cookies — Guardian is the upgrade. ## How to migrate from Cookie AutoDelete to Guardian The migration takes about 90 seconds in the happy path. Full ordered checklist: 1. **Export your Cookie AutoDelete whitelist**. While Cookie AutoDelete is still installed (on Firefox, or on a Chromium browser that has not yet force-disabled it), open its Settings page and choose "Export → Whitelist + Greylist". Save the JSON. 2. Download the verified Guardian ZIP from the [download page](/en/download/?product=guardian) and follow the manual installation steps; store listings are not yet available. 3. **Import the whitelist**. Click the Guardian toolbar icon → Settings (gear) → "Import → Cookie AutoDelete JSON". Select the file from step 1. 4. **Verify domains appear in the whitelist**. Switch to the Whitelist tab. Confirm every domain transferred. Subdomain inheritance is on by default — a single `example.com` entry covers `mail.example.com`. 5. **Test the cleanup workflow on a real site**. Open a non-whitelisted site, browse for a minute, close the tab, reopen — you should be logged out, localStorage cleared, IndexedDB cleared. If a site you expected to stay logged in does not, add it to the whitelist. 6. **Tune the cleanup scope**. Settings → Cleanup Targets — enable / disable each storage type independently. Defaults are sensible; narrow only if a critical site breaks. 7. **Enable encrypted whitelist sync (optional)**. Settings → Sync → create an account → choose a passphrase. The passphrase derives the encryption key client-side; the sync server stores only opaque ciphertext. 8. **Uninstall Cookie AutoDelete**. On any browser where it is still installed (typically Firefox), go to the extensions page and remove it. Keep the exported JSON for at least 30 days as a rollback option. If the import fails at step 3 with "unsupported format," your JSON may be from a pre-3.x Cookie AutoDelete version. Open an issue on the CookieVault GitHub repository with the file attached (scrub domain names that are sensitive) and we will add a compatibility shim. ## Frequently asked questions **Q: Why did Cookie AutoDelete stop working in Chrome?** Chrome disabled all Manifest V2 extensions in stable between June 2024 and early 2025. Cookie AutoDelete relied on a persistent MV2 background page that does not exist in MV3, and was not rewritten in time. **Q: Does Cookie AutoDelete still work in Firefox?** Yes. Firefox kept MV2 support. If you only use Firefox and your current setup works, there is no urgency to migrate. **Q: Will Guardian import my Cookie AutoDelete JSON?** Yes — full whitelist + greylist + wildcard + per-container associations. Open an issue if you hit a parse error. **Q: What does Guardian clean beyond cookies?** localStorage, sessionStorage, IndexedDB, Cache Storage, Service Worker registrations. Each toggleable. **Q: What sites break under Guardian's expanded cleanup?** Anything that stores state client-side without server backup — drafts in online editors, PWA offline caches, JS framework state caches. Whitelist them. **Q: Is the free tier limited?** The core cleanup workflow is included. Pro adds cross-device sync and 90-day cookie history. **Q: Is Guardian the same extension as CookieVault Editor?** No — two separate extensions. Install one, the other, or both. **Q: Can I undo Guardian's cleanup?** No — cookie and storage cleanup is irreversible once it runs. Whitelist sensitive sites; Pro's 90-day cookie history covers cookies (not other storage types) for accidental closures. --- [^1]: Cookie AutoDelete's Chrome Web Store listing displayed install counts publicly before the MV2 disablement. The "280,000 weekly active Chrome users" figure traces to Chrome Web Store statistics captured in Web Archive snapshots in 2023–2024 and is approximate. [^2]: Chrome's Manifest V2 sunset timeline is documented in developer.chrome.com/docs/extensions/develop/migrate and the stable-channel disablement schedule in developer.chrome.com/blog/resuming-the-transition-to-mv3. [^3]: The Cookie AutoDelete source code is at github.com/Cookie-AutoDelete/Cookie-AutoDelete under the MIT license. The repository remains visible and forkable; the Firefox Add-ons listing remains functional. [^4]: Discussions about Manifest V3 compatibility for Cookie AutoDelete are tracked across multiple GitHub issues in the project's repository. Searching the project issues for "manifest v3" surfaces the maintainer's published stance. ### alternatives/en/cookie-editor.md --- title: 'Cookie-Editor alternative — Open-source, encrypted-sync option' slug: cookie-editor description: 'CookieVault is an open-source Cookie-Editor alternative on Manifest V3. Same lightweight edit workflow, plus MIT-licensed code, end-to-end encrypted sync, and reproducible builds.' type: alternative locale: en cluster: migration author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookie-editor alternative secondaryKeywords: - cookie editor by moustachauve alternative - cookie-editor replacement - open source cookie editor - cookie editor vs cookievault - cookie editor extension alternative intent: commercial funnel: mofu schemaType: - SoftwareApplication - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Is Cookie-Editor a good extension? a: Yes. Cookie-Editor (by Moustachauve) is a well-maintained, Manifest V3-compatible cookie editor with a clean popup UI and a large install base. It is a perfectly reasonable choice. CookieVault is an alternative for users who specifically want open-source code, end-to-end encrypted sync, or reproducible builds — not a claim that Cookie-Editor is unsafe. - q: How is CookieVault different from Cookie-Editor? a: Three differences. CookieVault is MIT-licensed open source (Cookie-Editor is closed source). CookieVault offers optional end-to-end encrypted cross-device sync (Cookie-Editor is local-only). CookieVault publishes reproducible builds so you can verify the store binary against a Git commit. Cookie-Editor's advantages are a smaller install footprint and a longer track record. - q: Is Cookie-Editor open source? a: No. Cookie-Editor's binary is distributed through the extension stores but its source is not published under an OSI-approved open-source license that allows independent audit of the cookie-handling boundary. CookieVault publishes its Editor and Guardian extension code — including the client-side cryptographic boundary — under the MIT license (the hosted sync service stays proprietary). - q: Does Cookie-Editor have cloud sync? a: No. Cookie-Editor stores cookies locally and does not offer cross-device sync. CookieVault's Pro tier adds end-to-end encrypted sync — your cookies and profiles appear on all your devices, encrypted client-side so the sync server only ever holds ciphertext. - q: Can I import my Cookie-Editor cookies into CookieVault? a: Yes. Cookie-Editor exports to JSON; CookieVault Editor imports JSON and rehydrates each cookie through the chrome.cookies API, preserving name, value, domain, path, expires, httpOnly, secure, and sameSite. Export from Cookie-Editor, import into CookieVault, verify, done. - q: Which is faster or lighter? a: Cookie-Editor has a smaller install footprint (~120 KB vs CookieVault's ~480 KB, because CookieVault bundles the sync client and crypto library). For pure local editing with no sync, Cookie-Editor's popup opens marginally faster. If you do not need sync, history, or multi-profile, that smaller footprint is a genuine advantage. - q: Do both work on Firefox? a: Yes. Both Cookie-Editor and CookieVault Editor ship Firefox builds in addition to their Chromium builds. Feature parity is similar on Firefox; CookieVault adds the same encrypted-sync option there. - q: Should I switch from Cookie-Editor to CookieVault? a: Only if you want what CookieVault adds — open-source auditability, encrypted cross-device sync, cookie history with undo, or multi-account profiles. If Cookie-Editor's local-only editing already covers your workflow and you value the smaller footprint, there is no need to switch. We would rather you use the right tool than switch for switching's sake. --- # Cookie-Editor alternative > **TL;DR**: CookieVault is an open-source Cookie-Editor alternative on Manifest V3. It matches Cookie-Editor's lightweight per-site editing and adds MIT-licensed code, end-to-end encrypted cross-device sync, cookie history, and reproducible builds. Cookie-Editor remains a good choice for users who want the smallest footprint and do not need sync. CookieVault is a free, MIT-licensed cookie manager that serves as an open-source alternative to Cookie-Editor, the popular Manifest V3 cookie editor by Moustachauve. Both let you view, edit, add, and delete cookies from a per-site popup. The difference is that CookieVault publishes its source code, offers optional end-to-end encrypted sync, and ships reproducible builds — while Cookie-Editor is closed-source, local-only, and lighter weight. This page compares them honestly so you can pick on the merits. ## Cookie-Editor is a good extension > **In short**: This is not a teardown. Cookie-Editor is well-maintained, Manifest V3-compatible, and widely used. CookieVault competes on open-source transparency and sync, not by claiming Cookie-Editor is unsafe — because it is not. Per our content standards, we do not attack competitors. Cookie-Editor (by Moustachauve) is a legitimately good tool: a clean popup, fast local editing, a large and satisfied user base, and active maintenance on the current Manifest V3 platform. If you are happy with it, you have no urgent reason to leave. CookieVault exists for a specific subset of users — those who want to audit the source code, sync cookies across devices with zero-knowledge encryption, or verify the shipped binary against the published source. If none of those matter to you, Cookie-Editor's smaller footprint is a real point in its favor. ## What CookieVault adds > **In short**: Open-source code, end-to-end encrypted sync, cookie history with undo, multi-account profiles, and reproducible builds. These are the reasons to choose CookieVault over a closed-source local-only editor. Five capabilities CookieVault offers that Cookie-Editor does not: - **MIT-licensed open source** — the Editor and Guardian browser extensions, including the client-side cryptographic boundary, are public and auditable (the hosted sync service is proprietary). Independent reviewers can inspect exactly how cookies are read, written, and (optionally) synced. - **End-to-end encrypted sync** — passphrase-derived key (PBKDF2-SHA-256), per-record AES-256-GCM encryption, server stores only ciphertext. Your cookies appear on all devices without the provider being able to read them. - **Cookie history with undo** — 90-day history (Pro) lets you restore a cookie you edited or deleted by accident. - **Multi-account profiles** — named cookie snapshots for one-click identity switching (work vs personal) in a single browser window. - **Reproducible builds** — verify the Chrome Web Store binary matches a tagged Git commit by comparing SHA-256 checksums. ## What Cookie-Editor does better > **In short**: Smaller install, faster cold popup, no account ever, and a longer track record. For pure local editing, these are genuine advantages. Honesty cuts both ways. Three areas where Cookie-Editor has the edge: - **Smaller footprint** — roughly 120 KB packed versus CookieVault's ~480 KB. CookieVault carries the sync client and crypto library even if you never enable Pro. - **No account, ever** — Cookie-Editor never prompts for an account. CookieVault's local mode is identical, but the existence of a Pro/sync tier is visible in the UI. - **Longer track record** — Cookie-Editor has years of stable releases and a large review history. CookieVault is newer. ## Feature comparison | Criterion | CookieVault Editor | Cookie-Editor | | --------------------------------- | ------------------ | ------------- | | License | MIT (open source) | Closed source | | Manifest version | V3 | V3 | | Reproducible builds | Yes | No | | Per-site cookie edit popup | Yes | Yes | | Add / delete / search cookies | Yes | Yes | | Edit SameSite / HttpOnly / Secure | Yes | Yes | | Export JSON / Netscape / HAR | Yes | JSON | | End-to-end encrypted sync | Yes (Pro) | No | | Cookie history / undo | Yes (Pro) | No | | Multi-account profiles | Yes | No | | Install footprint | ~480 KB | ~120 KB | | Account required | No (Pro optional) | No | | Firefox build | Yes | Yes | | Active maintenance | Yes | Yes | ## How to migrate from Cookie-Editor If CookieVault's additions are worth it for you, migration takes about a minute: 1. Open Cookie-Editor on any site, click its export button, and save the JSON 2. Check the [download page](/en/download/?product=editor) for the verified Editor release status. The package is not yet publicly available. 3. Open CookieVault → Settings → Import → JSON 4. Select the file you exported in step 1 5. Verify your cookies appear with correct domains, values, and flags 6. Optionally enable Pro sync to replicate across devices ## See also - [CookieVault vs Cookie-Editor](/en/vs/cookie-editor/) — the head-to-head comparison - [CookieVault Editor](/en/editor/) — product overview - [EditThisCookie alternative](/en/alternatives/editthiscookie/) — the other major migration path - [Encrypted cloud sync](/en/features/encrypted-cloud-sync/) — how the sync works - [Open source](/en/open-source/) — license and reproducible builds - [What is a cookie?](/en/concepts/what-is-a-cookie/) — the underlying protocol ### alternatives/en/cookiebro.md --- title: 'Cookiebro alternative — Open-source Manifest V3 replacement' slug: cookiebro description: 'CookieVault is an open-source Cookiebro alternative on Manifest V3. Cookie management plus Cookie AutoDelete-style cleanup, MIT-licensed, with end-to-end encrypted sync.' type: alternative locale: en cluster: migration author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookiebro alternative secondaryKeywords: - cookiebro replacement - cookiebro manifest v3 - cookiebro open source alternative - cookie manager and auto delete - cookiebro vs cookievault intent: commercial funnel: mofu schemaType: - SoftwareApplication - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What is Cookiebro? a: Cookiebro is a browser extension that combines cookie viewing and editing with whitelist-based cookie management and auto-deletion. It bundles capabilities that CookieVault splits across two focused extensions — Editor (cookie management) and Guardian (auto-delete on tab close). - q: How is CookieVault different from Cookiebro? a: CookieVault is open source under the MIT license with reproducible builds; Cookiebro is closed source. CookieVault splits cookie editing (Editor) and auto-deletion (Guardian) into two focused extensions you can install independently, while Cookiebro bundles both into one. CookieVault also adds end-to-end encrypted cross-device sync. - q: Why does CookieVault use two extensions instead of one? a: Separation of concerns. Many users only need one capability — a developer editing cookies does not necessarily want auto-deletion running, and a privacy user wanting tab-close cleanup does not need a full cookie editor. Two focused extensions keep each lighter and let you grant only the permissions you actually use. You can install both for the full Cookiebro-equivalent feature set. - q: Can I replace Cookiebro's auto-delete with CookieVault? a: Yes — CookieVault Guardian provides the auto-delete-on-tab-close workflow with a whitelist, greylist, and wildcard patterns, and extends cleanup beyond cookies to localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations. Install Guardian for the cleanup half of Cookiebro's feature set. - q: Can I replace Cookiebro's cookie editing with CookieVault? a: Yes — CookieVault Editor provides the cookie viewing, editing, search, and export workflow, with attribute editing for SameSite, HttpOnly, Secure, and Expires. Install Editor for the management half of Cookiebro's feature set. - q: Is CookieVault free like Cookiebro? a: Yes. Both Editor and Guardian are free for all local features. CookieVault's optional Pro tier ($3.99/month) adds end-to-end encrypted cross-device sync, cookie history, and CSV/HAR export — features oriented around multi-device use, not a paywall on the core workflow. - q: Does CookieVault support Manifest V3? a: Yes, natively. Both Editor and Guardian are built for Manifest V3 from the ground up — ephemeral service workers, the official chrome.cookies API, no persistent background pages. This is the platform Chrome supports going forward after the Manifest V2 sunset. - q: How do I migrate from Cookiebro to CookieVault? a: Export your cookies and whitelist from Cookiebro (its settings offer JSON export), install CookieVault Editor and Guardian, then import the cookie JSON into Editor and the whitelist into Guardian. Verify both, and you have replicated Cookiebro's combined feature set across two focused extensions. --- # Cookiebro alternative > **TL;DR**: CookieVault is an open-source Cookiebro alternative on Manifest V3. It provides Cookiebro's combined feature set — cookie management plus whitelist-based auto-deletion — across two focused, MIT-licensed extensions (Editor and Guardian), and adds end-to-end encrypted sync. Install both for full Cookiebro parity, or just the half you need. CookieVault is a free, MIT-licensed alternative to Cookiebro that delivers the same two core capabilities — cookie management and whitelist-based auto-deletion — but as two focused extensions rather than one bundle. CookieVault Editor handles cookie viewing and editing; CookieVault Guardian handles auto-delete on tab close. Both are Manifest V3 native and open source, and Guardian's cleanup reaches beyond cookies to localStorage, IndexedDB, and other modern storage. ## What Cookiebro does, and how CookieVault maps to it > **In short**: Cookiebro bundles cookie editing and auto-deletion in one extension. CookieVault splits them into Editor (management) and Guardian (cleanup) so you install only what you need. Install both for the full Cookiebro-equivalent feature set. | Cookiebro capability | CookieVault equivalent | | ---------------------------------- | ----------------------------------- | | View / edit / add / delete cookies | CookieVault Editor | | Cookie whitelist | CookieVault Guardian whitelist | | Auto-delete unwanted cookies | CookieVault Guardian (on tab close) | | Block / filter cookies | Guardian default-deny + whitelist | | Export / import | Editor (JSON / Netscape / HAR) | ## Why two focused extensions > **In short**: Separation of concerns keeps each extension lighter and lets you grant only the permissions you use. A developer editing cookies does not need auto-deletion running; a privacy user wanting cleanup does not need a full editor. Three reasons CookieVault splits what Cookiebro bundles: - **Minimal permissions** — Editor requests cookie access; Guardian requests the broader browsingData access needed for cleanup. Installing only one means granting only the permissions that feature actually requires. - **Lighter footprint per extension** — you are not carrying auto-delete machinery if you only edit cookies, or a full editor UI if you only want cleanup. - **Independent updates** — each extension ships on its own cadence, so a fix to one does not require re-reviewing the other. You can, of course, install both — and most users replacing Cookiebro will — for the complete combined feature set, sharing a single Pro account across them. ## What CookieVault adds over Cookiebro > **In short**: Open-source code, Manifest V3-native architecture, expanded cleanup scope, and end-to-end encrypted sync. - **MIT open source + reproducible builds** — Cookiebro is closed source; CookieVault publishes the full source of both extensions — Editor and Guardian — and lets you verify the store binary against a Git commit. - **Expanded cleanup scope** — Guardian cleans localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations, not just cookies. - **End-to-end encrypted sync** — cookies, profiles, and whitelist rules replicate across devices with client-side encryption (Pro). - **Manifest V3 native** — built on the platform Chrome supports going forward. ## Feature comparison | Criterion | CookieVault (Editor + Guardian) | Cookiebro | | --------------------------------------- | ------------------------------- | --------------------- | | License | MIT (open source) | Closed source | | Manifest version | V3 | Check current listing | | Architecture | Two focused extensions | Single bundle | | Cookie view / edit / delete | Yes (Editor) | Yes | | Cookie whitelist | Yes (Guardian) | Yes | | Auto-delete on tab close | Yes (Guardian) | Yes | | Cleans localStorage / IndexedDB / Cache | Yes (Guardian) | Cookies-focused | | Export JSON / Netscape / HAR | Yes (Editor) | Export available | | End-to-end encrypted sync | Yes (Pro) | No | | Reproducible builds | Yes | No | | Firefox build | Yes | Check current listing | ## How to migrate from Cookiebro 1. Open Cookiebro settings and export your cookies and whitelist (JSON) 2. Use the [download page](/en/download/) for verified releases: Guardian is available as a manual ZIP, while Editor is not yet publicly available. 3. Import the cookie JSON into Editor (Settings → Import) 4. Import the whitelist into Guardian (Settings → Import) 5. Verify cookies appear in Editor and whitelist domains appear in Guardian 6. Test Guardian's cleanup on a non-whitelisted site, then enable Pro sync if you want cross-device replication ## See also - [CookieVault Editor](/en/editor/) — cookie management half - [CookieVault Guardian](/en/guardian/) — auto-delete half - [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/) — if you primarily want cleanup - [EditThisCookie alternative](/en/alternatives/editthiscookie/) — if you primarily want editing - [Pricing](/en/pricing/) — Free / Pro / Team breakdown - [What is a cookie?](/en/concepts/what-is-a-cookie/) — the underlying protocol ### alternatives/en/editthiscookie.md --- title: 'EditThisCookie alternatives (2026): safe MV3 options' slug: editthiscookie description: 'Compare safe Manifest V3 alternatives to EditThisCookie for Chrome, Edge, Brave and Firefox, including open-source status, privacy and migration steps.' type: alternative locale: en cluster: migration author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-11 primaryKeyword: editthiscookie alternative secondaryKeywords: - editthiscookie replacement - safe editthiscookie alternative - best editthiscookie alternative chrome - editthiscookie removed - editthiscookie not working intent: commercial funnel: bofu schemaType: - SoftwareApplication - FAQPage - HowTo geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true howToSteps: - name: Export your existing data text: While EditThisCookie is still installed locally, click its toolbar icon, open the menu, and choose "Export → JSON". Save the file somewhere you can find it. - name: Uninstall EditThisCookie text: Visit chrome://extensions, find EditThisCookie, and click Remove. The Chrome Web Store listing is gone, so a fresh re-install is not an option anyway. - name: Install CookieVault Editor text: Open the CookieVault download page and check the Editor release status. The Editor package is not yet publicly available; do not install similarly named third-party extensions. - name: Open the Editor and import text: Click the new CookieVault toolbar icon, open Settings (gear), and choose "Import → EditThisCookie JSON". Select the file you exported in step 1. - name: Verify the cookie list populated text: Switch back to the Editor's main popup. Visit any site where you previously had session cookies. The cookies should appear in the list with correct domains, values, and expiry timestamps. - name: Test a known login text: Navigate to a site whose login depends on imported cookies (your work tool, a personal forum, etc.). The session should be active; if not, the underlying cookie may have expired before import. - name: Enable encrypted sync (optional) text: If you want cookies available on a second device, open Settings → Sync, create an account, and pick a passphrase. The passphrase derives the encryption key client-side — CookieVault servers never see your cookies in plaintext. - name: Delete the EditThisCookie JSON export text: After verifying everything works, securely delete the JSON file from disk. Cookies in plaintext on disk are a credential leak risk. faq: - q: Why was EditThisCookie removed from the Chrome Web Store? a: Google removed EditThisCookie from the Chrome Web Store on 2024-09-28 after community reports that the maintainer account had been transferred and the new owner pushed updates with aggressive monetization that violated Chrome Web Store policies. The original codebase on GitHub remains under its open-source license, but the store listing is gone. - q: Is the old EditThisCookie binary still safe to use if I have it installed? a: We recommend uninstalling. Even if the version currently on your machine is the trusted pre-transfer build, it relies on Manifest V2 APIs which Chrome is phasing out. Once Chrome force-disables the last MV2 extensions, your data will be locked in an unmaintained extension. Migrate while it can still export. - q: Will CookieVault import my EditThisCookie JSON without losing flags? a: Yes. EditThisCookie's JSON format includes name, value, domain, path, expires, httpOnly, secure, sameSite, and storeId. CookieVault's importer parses all of these fields and rehydrates them through the official chrome.cookies API, preserving every flag. - q: Is CookieVault open source like EditThisCookie was? a: Yes. The CookieVault Editor and Guardian browser extensions — including the client-side cryptographic boundary — are MIT-licensed and published on GitHub. Reproducible builds let you verify the Chrome Web Store binary matches a specific tagged commit. The hosted sync service is proprietary and not self-hostable. - q: Does CookieVault work in Edge, Brave, Opera, Vivaldi, Arc, and Firefox? a: Yes — all six. The Chromium-based browsers (Edge, Brave, Opera, Vivaldi, Arc) install the same Chrome Web Store build. Firefox uses a separate Manifest V3-compatible build published on the Firefox Add-ons site. - q: Is there a cost? a: Local cookie management is free forever. The Pro tier ($3.99/month or $29/year) unlocks end-to-end encrypted cross-device sync, cookie history with undo, named profiles, and CSV/HAR export. No tier limits the number of cookies you can manage locally. - q: How is "end-to-end encrypted sync" different from regular cloud sync? a: End-to-end encrypted means the encryption key is derived on your device from a passphrase only you know, and never leaves the device in plaintext. CookieVault's sync server stores only opaque ciphertext that CookieVault engineers cannot decrypt. By contrast, most "cloud sync" features encrypt in transit and at rest but the provider holds the key. - q: What if I do not have an EditThisCookie JSON export and the extension is already gone? a: You can manually copy cookies from Chrome DevTools (F12 → Application → Cookies) and recreate them in CookieVault Editor's "Add cookie" dialog. Tedious for large lists, but no information is unrecoverable as long as the browser profile is intact. --- # EditThisCookie alternative > **TL;DR**: CookieVault is the open-source, Manifest V3-native EditThisCookie alternative. It restores the full Editor workflow on every Chromium browser plus Firefox, adds end-to-end encrypted sync, and ships with reproducible builds — migration from EditThisCookie takes about 90 seconds. CookieVault is a free, MIT-licensed cookie manager browser extension that provides a Manifest V3 replacement for EditThisCookie, the Chrome Web Store cookie editor that was removed on 2024-09-28. CookieVault restores the same per-site Editor workflow developers and QA engineers relied on, adds end-to-end encrypted cross-device sync, and publishes the full source of both browser extensions on GitHub under the MIT license. ## What happened to EditThisCookie > **In short**: EditThisCookie was the dominant Chrome cookie editor for a decade with a reported install base in the millions[^1]. Google removed the extension from the Chrome Web Store on 2024-09-28 following community-surfaced[^2] evidence that the maintainer account had changed hands and a post-transfer update had introduced unwanted monetization. The original GitHub repository[^3] remains visible under the MIT license, but the official store listing is permanently gone. EditThisCookie ran on Manifest V2, the older Chrome extension API that Google has been actively retiring since 2019[^4]. Even if the listing had survived the maintainer-transfer incident, the extension would soon have been broken by the Manifest V3 transition: as of June 2024, Chrome began disabling all MV2 extensions in the stable channel, with no upgrade path for extensions that have not been rewritten[^4]. Anything still relying on the deprecated `chrome.extension.getBackgroundPage` API, persistent background pages, or blocking `webRequest` interception will stop working in 2025. The original author, Francesco Capano, has publicly stated[^2] that he sold the extension to a third party prior to the malicious updates and has not been involved in its development for years. We do not blame him for the removal — we simply note that maintainer-account transfers are a known supply-chain risk for browser extensions, and the EditThisCookie story is a textbook example. ## Why you need a replacement now > **In short**: Three forces converge on EditThisCookie users in 2025. The Chrome Web Store listing is gone, so there is no in-store update path. The local binary, even if pre-transfer, relies on a deprecated Manifest V2 architecture that Chrome will stop loading. And privately-circulated post-removal forks have an unknown provenance and should not be trusted with credential data. Three independent forces converge on EditThisCookie users in 2025: 1. **No Chrome Web Store listing.** New users cannot install the extension. Existing users cannot receive any update — security fix or otherwise. The listing is gone[^5]. 2. **Manifest V2 sunset in Chrome stable.** Chrome's official documentation[^4] gives the timeline: starting June 2024, MV2 extensions are disabled in the stable channel; by January 2025 the disablement is irreversible. Enterprise policies allowed a brief extension into mid-2025, but the policy itself is being retired. 3. **Untrusted forks circulating outside the store.** Several "EditThisCookie revival" extensions and standalone CRX files have appeared on GitHub, mirror sites, and search-result top hits. None publish their build provenance. Installing an extension with `chrome.cookies` permission from an unknown publisher is a credential-theft vector. The conservative path is to migrate to a maintained, audit-friendly Manifest V3 alternative with a clear ownership chain before the next Chrome update breaks your local copy. ## What to look for in a replacement A trustworthy EditThisCookie replacement should meet at least six criteria. CookieVault meets all six; we list them so you can verify any alternative — including ours — against the same checklist: - **Open-source code.** MIT, Apache 2.0, or BSD — anything OSI-approved that lets independent reviewers audit the cookie-handling boundary. - **Manifest V3 native.** Built for the current Chrome extension API, not a hasty wrapper around an MV2 codebase. Verify by inspecting `manifest.json` for `"manifest_version": 3`. - **Public maintainer identity.** Real names, real LinkedIn / GitHub profiles, and a documented company or organization. Pseudonymous publishers should be a yellow flag. - **Reproducible Chrome Web Store builds.** The published binary should be byte-identical to a tagged Git commit. Reproducibility eliminates the "the source code says X but the published binary does Y" attack class. - **No analytics SDKs.** A cookie-management extension that ships Google Analytics, Mixpanel, or any third-party telemetry has its threat model exactly backward. - **A transparent business model.** The extension is either funded by a paid Pro tier (CookieVault's model), donations, a foundation, or a sponsor; "free with no apparent income source" is exactly the kind of project that gets sold to a malicious actor down the road. ## CookieVault vs other EditThisCookie alternatives The major modern alternatives are CookieVault, Cookie-Editor, and a handful of post-removal EditThisCookie forks. Side-by-side: | Criterion | CookieVault Editor | Cookie-Editor | EditThisCookie revival forks | | ----------------------------------- | ------------------ | ------------------ | ---------------------------- | | License | MIT (open source) | Closed proprietary | Mixed; some undisclosed | | Manifest version | V3 | V3 | Mostly V2 (deprecated) | | Reproducible Chrome Web Store build | Yes | No | Not documented | | End-to-end encrypted cloud sync | Yes (Pro) | No | No | | Multi-account profiles | Yes | No | No | | Cookie history / undo | Yes (Pro) | No | No | | Maintainer identity public | Yes | Yes | Often pseudonymous | | Telemetry SDKs | None | None known | Several confirmed[^6] | | Active maintenance | Yes | Yes | Varies | | Firefox build | Yes | Yes | Some | The honest summary: Cookie-Editor is a perfectly reasonable choice if all you need is the popup UX and you do not care about source-code transparency or sync. CookieVault wins on auditability and on the encrypted-sync feature that EditThisCookie never had. The unmaintained or anonymous forks are not in the same category — they are credential-theft risk that no convenience benefit justifies. ## How to migrate from EditThisCookie to CookieVault Migration takes about 90 seconds in the happy path. The full ordered checklist: 1. **Export your existing data.** While EditThisCookie is still installed locally, click its toolbar icon, open the menu, and choose "Export → JSON". Save the file somewhere you can find it. 2. **Uninstall EditThisCookie.** Visit `chrome://extensions`, find EditThisCookie, and click Remove. The Chrome Web Store listing is gone, so a fresh re-install is not an option anyway. 3. **Check CookieVault Editor availability.** Open the [download page](/en/download/?product=editor) for the current verified status. The Editor package is not yet publicly available. 4. **Open the Editor and import.** Click the new CookieVault toolbar icon, open Settings (gear), and choose "Import → EditThisCookie JSON". Select the file you exported in step 1. 5. **Verify the cookie list populated.** Switch back to the Editor's main popup. Visit any site where you previously had session cookies. The cookies should appear in the list with correct domains, values, and expiry timestamps. 6. **Test a known login.** Navigate to a site whose login depends on imported cookies. The session should be active; if not, the underlying cookie may have expired before import. 7. **Enable encrypted sync (optional).** If you want cookies available on a second device, open Settings → Sync, create an account, and pick a passphrase. The passphrase derives the encryption key client-side — CookieVault servers never see your cookies in plaintext. 8. **Delete the EditThisCookie JSON export.** After verifying everything works, securely delete the JSON file from disk. Cookies in plaintext on disk are a credential leak risk for as long as the file exists. If the import fails at step 4 with "unsupported format," the JSON may be from a pre-2.0 EditThisCookie release. Open an issue on the CookieVault GitHub repository with the file attached (after redacting cookie values) and we will add a compatibility shim. ## Frequently asked questions **Q: Why was EditThisCookie removed from the Chrome Web Store?** Google removed it on 2024-09-28 after community reports that the maintainer account had been transferred and the new owner pushed updates with aggressive monetization. The original GitHub codebase remains under its open-source license; the store listing does not. **Q: Is the old EditThisCookie binary still safe to use if I have it installed?** We recommend uninstalling. Even the trusted pre-transfer build relies on Manifest V2 APIs that Chrome is force-disabling in 2025. Once that happens, your data will be locked in an unmaintained extension that no longer runs. **Q: Will CookieVault import my EditThisCookie JSON without losing flags?** Yes. The JSON format includes name, value, domain, path, expires, httpOnly, secure, sameSite, and storeId; CookieVault's importer parses all of these and rehydrates them through `chrome.cookies.set`. **Q: Is CookieVault open source the way EditThisCookie was?** Yes — MIT license on GitHub, reproducible Chrome Web Store builds, public commit history. **Q: Does CookieVault work on Edge, Brave, Opera, Vivaldi, Arc, and Firefox?** Yes, all six. Chromium browsers install the same Chrome Web Store build; Firefox uses a separate MV3-compatible build on the Firefox Add-ons site. **Q: Is there a cost?** Local cookie management is free forever. The Pro tier ($3.99/month or $29/year) adds encrypted cross-device sync, cookie history with undo, named profiles, and CSV/HAR export. **Q: How is "end-to-end encrypted sync" different from regular cloud sync?** The encryption key is derived on your device from a passphrase only you know and never leaves the device in plaintext. The sync server holds only opaque ciphertext. With traditional cloud sync, the provider holds the key. **Q: What if I do not have an EditThisCookie JSON export and the extension is already gone?** Copy cookies manually from Chrome DevTools (F12 → Application → Cookies) into CookieVault Editor's "Add cookie" dialog. Tedious for large lists, but recoverable as long as the browser profile is intact. --- [^1]: EditThisCookie's install count was publicly displayed on its Chrome Web Store listing prior to removal. The exact figure varies across archived captures; the often-quoted "3 million users" figure traces to Web Archive snapshots of the listing in 2023–2024. We have not independently verified the peak number and treat it as approximate. [^2]: Reports of the maintainer-account transfer and subsequent monetization changes were discussed across the developer community in September 2024. The original author, Francesco Capano, has publicly addressed the situation on his personal channels. [^3]: Multiple community-archived forks of the EditThisCookie source code remain on GitHub under the original MIT license; none of them has authoritative post-removal status, and we deliberately do not link a specific fork here because doing so would imply endorsement. Visibility of any of these sources does not imply that side-loading the build is safe — see "untrusted forks" above. [^4]: Chrome's official Manifest V3 transition timeline is published at developer.chrome.com/docs/extensions/develop/migrate and the stable-channel disablement schedule at developer.chrome.com/blog/resuming-the-transition-to-mv3. Enterprise extension policy timelines are at developer.chrome.com/docs/extensions/develop/migrate/improve-security. [^5]: Direct verification: searching the Chrome Web Store for "edit this cookie" as of 2024-Q4 returns the message "The item you have requested is not available" for the original listing ID. [^6]: Specific telemetry behavior of each post-removal fork has been audited piecemeal by the security community. We do not link individual forks here because doing so would amount to a recommendation. If you must use one, audit `manifest.json` permissions and search the source tree for analytics endpoints before installing. ### blog/en/cookie-autodelete-disabled.md --- title: 'Cookie AutoDelete is disabled in Chrome — what happened and what to do' slug: cookie-autodelete-disabled description: 'Cookie AutoDelete stopped working in Chrome after the Manifest V2 sunset disabled it in late 2024. Here is why, what you lost, and the Manifest V3 alternatives that still auto-clean cookies.' type: blog locale: en cluster: migration category: privacy accent: guardian author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookie autodelete disabled chrome secondaryKeywords: - cookie autodelete not working - cookie autodelete stopped working chrome - cookie autodelete manifest v3 - cookie autodelete chrome alternative - why did cookie autodelete stop working intent: informational funnel: mofu schemaType: - Article - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Why did Cookie AutoDelete stop working in Chrome? a: Chrome disabled all Manifest V2 extensions in its stable channel as part of the long-planned Manifest V3 transition, which rolled out from June 2024 and completed in early 2025. Cookie AutoDelete relied on a persistent MV2 background page to track tab-close lifecycle and was not rewritten for Manifest V3, so it was disabled along with thousands of other MV2 extensions. - q: Is Cookie AutoDelete gone for good on Chrome? a: On Chrome stable, yes — Manifest V2 disablement is policy, not a bug, and it is not reversible. There is no announced plan to rewrite Cookie AutoDelete for Manifest V3. The GitHub repository remains public under the MIT license, so the community could fork and rewrite it, but no mature MV3 fork exists as of this writing. - q: Does Cookie AutoDelete still work in Firefox? a: Yes. Firefox kept Manifest V2 support, and the maintained Cookie AutoDelete build on Firefox Add-ons continues to install and function. If you only use Firefox and your current setup works, there is no urgency to migrate. - q: What is the best Cookie AutoDelete alternative for Chrome? a: CookieVault Guardian is a Manifest V3-native successor that restores the tab-close auto-cleanup workflow, matches the whitelist / greylist / wildcard model, and extends cleanup beyond cookies to localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations. It is free and MIT-licensed. - q: Can I transfer my Cookie AutoDelete whitelist to a new extension? a: Yes. While Cookie AutoDelete is still installed (on Firefox, or a not-yet-disabled Chromium browser), export your whitelist via Settings → Export. CookieVault Guardian can import that JSON and rehydrate your whitelist, greylist, and expression-matching rules. - q: What is the difference between Manifest V2 and V3 that caused this? a: Manifest V3 replaces persistent background pages with ephemeral service workers and requires declarative APIs in places where V2 allowed imperative ones. Cookie AutoDelete's tab-lifecycle tracking was built on a persistent V2 background page, so it needed substantial reengineering to run on V3 — work the maintainers indicated was not on their roadmap. - q: Did I lose my cookie cleanup when Cookie AutoDelete was disabled? a: If you were on Chrome / Edge / Brave / Opera / Vivaldi / Arc, yes — when the extension was disabled, automatic tab-close cleanup stopped. Cookies, localStorage, and other site data now persist until you clear them manually or install a Manifest V3 replacement that restores the auto-cleanup behavior. - q: How do I migrate from Cookie AutoDelete to CookieVault Guardian? a: Export your Cookie AutoDelete whitelist as JSON, download the verified CookieVault Guardian ZIP from our download page, follow the manual installation steps, then import and verify your domains. Store listings are not yet available. --- # Cookie AutoDelete is disabled in Chrome — what happened and what to do > **TL;DR**: Chrome disabled all Manifest V2 extensions in its stable channel by early 2025, and Cookie AutoDelete — which was never rewritten for Manifest V3 — was disabled along with them. It still works on Firefox. For Chromium browsers, the Manifest V3 successor is CookieVault Guardian, which restores tab-close cleanup and extends it beyond cookies. Cookie AutoDelete is the privacy-community extension that automatically deleted cookies when you closed a browser tab — and on Chromium browsers it no longer works. The cause was not a bug or a maintainer dispute; it was the completion of Chrome's long-planned Manifest V2 sunset[^1]. This post explains what happened, the architectural reason a beloved extension could not simply be patched, and the Manifest V3 path forward. ## What happened > **In short**: Cookie AutoDelete had a reported peak of around 280,000 weekly active Chrome users[^2]. Chrome's Manifest V2 sunset disabled all MV2 extensions in the stable channel between June 2024 and early 2025. Cookie AutoDelete depended on a persistent MV2 background page and was not rewritten for MV3, so it was caught in the disablement wave. Google announced the Manifest V3 transition in 2019 and published a phased timeline[^1]. The final phase — disabling all Manifest V2 extensions in Chrome stable — began rolling out in June 2024 and completed in early 2025. Cookie AutoDelete was one of thousands of privacy and ad-blocking extensions affected. The extension was created by Kenny Do and maintained as a community open-source project under the `Cookie-AutoDelete` GitHub organization[^3]. Its core mechanism — listening to tab-removal events from a persistent background page and reconciling the open-tab set against the cookie store — was built on exactly the MV2 architecture that Manifest V3 removed. ## Why it could not just be patched > **In short**: Manifest V3 is not a minor API revision — it removes the persistent background page Cookie AutoDelete's tab-tracking logic depended on, replacing it with ephemeral service workers. Porting the extension meant re-engineering its core, which the maintainers indicated was not on their roadmap. Three architectural changes in Manifest V3 that broke the extension: - **No persistent background page.** MV3 replaces the always-running background page with a service worker that the browser can terminate at any time. Cookie AutoDelete's tab-lifecycle tracking assumed a process that never stopped. - **Declarative-first APIs.** MV3 pushes extensions toward declarative APIs (e.g., declarativeNetRequest) and away from the imperative patterns MV2 allowed. Some of Cookie AutoDelete's logic had no direct declarative equivalent. - **Stricter lifecycle guarantees.** Reliable "the last tab on this domain just closed, clean now" detection is harder when your code can be suspended mid-operation, requiring a different state-management approach. The maintainers signalled[^3] that the MV3 rewrite was not a priority. The repository remains open under the MIT license — a community fork could undertake the rewrite — but none has reached maturity. ## What you lost (and on which browsers) > **In short**: On Chrome / Edge / Brave / Opera / Vivaldi / Arc, you lost automatic tab-close cleanup entirely. On Firefox, nothing changed — Cookie AutoDelete still works there because Firefox kept Manifest V2 support. Browser-by-browser status as of 2026: | Browser | Cookie AutoDelete status | What you should do | | --------------- | ------------------------ | ----------------------------------------------- | | Chrome | Disabled (MV2 sunset) | Migrate to a Manifest V3 alternative | | Edge (Chromium) | Disabled | Migrate | | Brave | Disabled | Migrate | | Opera | Disabled | Migrate | | Vivaldi | Disabled | Migrate | | Arc | Disabled | Migrate | | Firefox | Still works (MV2 kept) | No urgency; migrate only for cross-browser sync | If you were relying on Cookie AutoDelete for privacy hygiene on a Chromium browser, the gap is real: cookies, localStorage, and other site data now persist across sessions until you clear them manually. ## What to do > **In short**: On Chromium browsers, install a Manifest V3 successor that restores tab-close cleanup. On Firefox, you can stay on Cookie AutoDelete or migrate for the broader storage coverage and cross-browser whitelist sync. The seven-step migration checklist: 1. **Identify your browser** — if Firefox-only and satisfied, you can stop here 2. **Export your Cookie AutoDelete whitelist** — while it is still installed, Settings → Export → save JSON 3. Download the verified Guardian ZIP from the [download page](/en/download/?product=guardian) and follow the manual installation steps; store listings are not yet available. 4. **Import the whitelist** — Guardian Settings → Import → Cookie AutoDelete JSON 5. **Verify your domains transferred** — check the Whitelist tab 6. **Test cleanup** — visit a non-whitelisted site, close the tab, reopen, confirm you are logged out 7. **Tune cleanup targets** — enable/disable storage types if a specific site breaks ## The Manifest V3 alternative > **In short**: CookieVault Guardian is a strict superset of Cookie AutoDelete — same whitelist / greylist UX, plus localStorage / IndexedDB / Cache Storage / Service Worker cleanup that Cookie AutoDelete never had. Free and MIT-licensed. What Guardian carries over from Cookie AutoDelete, and what it adds: - **Carried over**: tab-close cleanup, whitelist, greylist, wildcard patterns, Firefox container support, manual "clean now" button - **Added**: localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker cleanup; cross-device whitelist sync (Pro); Manifest V3 compatibility - **Honest tradeoff**: Guardian's install is larger (~480 KB vs ~150 KB) and it is newer on Firefox, where Cookie AutoDelete has a multi-year track record The full feature-parity matrix and migration guide is on our [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/) page. ## See also - [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/) — full migration guide and feature matrix - [CookieVault Guardian vs Cookie AutoDelete](/en/vs/cookie-autodelete/) — direct comparison - [CookieVault Guardian](/en/guardian/) — the Manifest V3 successor - [Auto-delete cookies on tab close](/en/how-to/auto-delete-on-tab-close/) — setup walkthrough - [EditThisCookie is gone](/en/blog/editthiscookie-rip/) — the parallel story for the cookie editor - [What is a cookie?](/en/concepts/what-is-a-cookie/) — the underlying protocol --- [^1]: Chrome's Manifest V3 transition timeline is published at https://developer.chrome.com/docs/extensions/develop/migrate and the stable-channel MV2 disablement schedule at https://developer.chrome.com/blog/resuming-the-transition-to-mv3. [^2]: Cookie AutoDelete's Chrome Web Store listing displayed install counts before the MV2 disablement; the "280,000 weekly active users" figure traces to Web Archive snapshots in 2023-2024 and is approximate. We have not independently verified the peak number. [^3]: The Cookie AutoDelete source code is at https://github.com/Cookie-AutoDelete/Cookie-AutoDelete under the MIT license. The maintainer's Manifest V3 stance can be found by searching the project's GitHub issues for "manifest v3." ### blog/en/editthiscookie-rip.md --- title: 'Why EditThisCookie was removed (2026)' slug: editthiscookie-rip description: 'Why EditThisCookie disappeared from the Chrome Web Store, what happened after its maintainer-account transfer, and which Manifest V3 options are safer now.' type: blog locale: en cluster: migration category: product accent: editor featured: true author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-11 primaryKeyword: what happened to editthiscookie secondaryKeywords: - editthiscookie removed chrome - editthiscookie gone - editthiscookie not working - editthiscookie chrome web store removed - is editthiscookie safe intent: informational funnel: mofu schemaType: - Article - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What happened to EditThisCookie? a: EditThisCookie was removed from the Chrome Web Store on 2024-09-28. The community-surfaced explanation is that the maintainer account changed hands and a post-transfer update introduced unwanted monetization that violated Chrome Web Store policy. The original open-source code remains on GitHub, but the store listing is gone, so new users cannot install it and existing users get no updates. - q: Is EditThisCookie safe to keep using? a: We recommend uninstalling. Even if your locally installed copy is the trusted pre-transfer build, it runs on Manifest V2, which Chrome is force-disabling in its stable channel. Once disabled, your data is locked in an extension that no longer runs. And any "EditThisCookie" you reinstall from outside the official store has unverified provenance — a real risk for an extension with cookie access. - q: Why was EditThisCookie removed and not just updated? a: Google removes Chrome Web Store listings when an extension violates policy — in this case, the monetization behavior introduced after the maintainer-account transfer. Removal is not the same as a forced update; Google took down the listing entirely rather than reverting it, which is why there is no "updated EditThisCookie" in the store. - q: What is the best EditThisCookie alternative? a: For a like-for-like cookie editor on Manifest V3, CookieVault Editor reproduces the EditThisCookie workflow (view, edit, export, import) and adds end-to-end encrypted sync and reproducible builds. Cookie-Editor (by Moustachauve) is another actively maintained MV3 option. Both are safe; CookieVault is open source, Cookie-Editor is closed source. - q: Will my EditThisCookie cookies transfer to a new extension? a: Yes, if you export them first. While EditThisCookie is still installed, use its Export → JSON feature. CookieVault Editor (and most modern cookie managers) can import that JSON and restore your cookies with all flags intact. If you have already uninstalled EditThisCookie, you can recreate cookies manually from Chrome DevTools. - q: Is the EditThisCookie on GitHub safe to build myself? a: The original source code on GitHub is open and inspectable, so building it yourself is safer than installing an unverified binary from a third party. However, it still relies on Manifest V2, so a self-built copy will stop working when Chrome fully disables MV2. A Manifest V3 alternative is the durable choice. - q: Did EditThisCookie steal passwords or data? a: There is no broad public confirmation that the post-transfer EditThisCookie exfiltrated passwords. The documented concern was policy-violating monetization behavior, not confirmed credential theft. That said, an extension with cookie access under unknown ownership is a credible risk, which is why the community moved off it quickly. - q: How do I migrate from EditThisCookie to CookieVault? a: Export your cookies from EditThisCookie as JSON and keep the file safe. CookieVault Editor is not yet publicly available; check our download page for the verified release status and do not install similarly named third-party extensions. --- # EditThisCookie is gone — what happened and what to do > **TL;DR**: EditThisCookie was removed from the Chrome Web Store on 2024-09-28 after the maintainer account was reportedly transferred and a post-transfer update added policy-violating monetization. The original is defunct; the safe path is a Manifest V3 alternative like the open-source CookieVault Editor or the closed-source Cookie-Editor. The removal of EditThisCookie is one of the most consequential events in Chrome extension history. EditThisCookie was, for nearly a decade, the default cookie editor for millions of Chrome users[^1] — and on 2024-09-28 it disappeared from the Chrome Web Store. This post lays out the verifiable timeline, explains why an extension that was trusted for years became a risk, and tells you exactly what to do whether you still have it installed or not. ## The timeline > **In short**: EditThisCookie grew to a multi-million install base over roughly a decade, ran on Manifest V2, and was removed from the Chrome Web Store on 2024-09-28 following a maintainer-account transfer and a controversial post-transfer update. The GitHub source remains; the store listing does not. The sequence of events, as documented across the developer community[^2]: | Date / period | Event | | -------------------- | --------------------------------------------------------------------------------------------------- | | ~2012-2023 | EditThisCookie is the dominant Chrome cookie editor, reaching a reported multi-million install base | | 2019 onward | Google announces and begins the Manifest V3 transition, deprecating MV2[^3] | | Pre-2024 | The original author, Francesco Capano, transfers the extension to a third party | | 2024 (post-transfer) | A new update introduces monetization behavior that the community flags as policy-violating | | 2024-09-28 | Google removes EditThisCookie from the Chrome Web Store | | 2024 onward | "EditThisCookie revival" forks and side-loadable CRX files appear from unverified publishers | The original author has publicly stated that he sold the extension before the problematic updates and was not involved in the changes that led to removal. We do not attribute the removal to him — the point is that maintainer-account transfers are a recognized supply-chain risk for browser extensions, and EditThisCookie is the textbook case. ## Why a trusted extension became a risk overnight > **In short**: Browser extensions have privileged access to your browsing data. An extension trustworthy for years can become a tracking or monetization vector the moment its publisher account changes hands — and users rarely notice the ownership change before the behavior changes. Three structural reasons this happens, and not just to EditThisCookie: - **Privileged access persists across ownership.** An extension with the `cookies` permission keeps that permission after a sale. The new owner inherits access to every cookie on every site you visit. - **Auto-update is silent.** Chrome updates extensions in the background. A policy-violating update can land without you clicking anything, and the new behavior runs with the permissions you granted the old owner. - **Provenance is invisible in the store.** The Chrome Web Store listing does not show ownership history. You cannot tell from the store page whether the extension you trusted in 2022 has the same owner in 2024. This is why open-source code and reproducible builds matter: they make the "the binary does something different from what the source says" attack class detectable. ## What to do right now > **In short**: If you still have EditThisCookie installed, export your data and uninstall. Then pick a Manifest V3 alternative with transparent ownership. Do not reinstall EditThisCookie from outside the official store. The eight-step safe-migration checklist: 1. **Check if EditThisCookie is still installed** — visit `chrome://extensions` and look for it 2. **If installed, export your cookies first** — click the EditThisCookie icon → Export → JSON, and save the file 3. **Uninstall EditThisCookie** — click Remove on the `chrome://extensions` page 4. **Do not reinstall from third-party sources** — "EditThisCookie revival" CRX files have unverified provenance 5. **Pick a Manifest V3 alternative** — CookieVault Editor (open source) or Cookie-Editor (closed source) are both safe 6. **Install from the official Chrome Web Store** — never from a direct download link in a search result 7. **Import your exported JSON** — CookieVault Editor: Settings → Import → EditThisCookie JSON 8. **Securely delete the exported JSON** once import is verified — plaintext cookies on disk are a credential-leak risk ## Which alternative to pick > **In short**: CookieVault Editor if you want open-source code, encrypted sync, and reproducible builds. Cookie-Editor if you want the smallest possible install and do not need sync. Both are Manifest V3 and actively maintained — avoid unmaintained forks. A short comparison of the safe options: - **CookieVault Editor** — MIT open source, Manifest V3, end-to-end encrypted sync, reproducible builds, multi-profile. The closest like-for-like EditThisCookie replacement with added trust signals. - **Cookie-Editor (by Moustachauve)** — closed source, Manifest V3, actively maintained, smallest footprint. A reasonable choice if source transparency is not a requirement for you. - **Unmaintained "revival" forks** — avoid. Unknown provenance plus cookie access is exactly the risk that took down the original. The full migration walk-through with screenshots and a feature-parity matrix is on our [EditThisCookie alternative](/en/alternatives/editthiscookie/) page. ## See also - [EditThisCookie alternative](/en/alternatives/editthiscookie/) — full migration guide and feature matrix - [CookieVault vs EditThisCookie](/en/vs/editthiscookie/) — direct comparison - [CookieVault Editor](/en/editor/) — the open-source replacement - [What is a cookie?](/en/concepts/what-is-a-cookie/) — the underlying protocol - [Cookie AutoDelete is disabled](/en/blog/cookie-autodelete-disabled/) — the parallel story for the auto-delete extension - [How to edit cookies in Chrome](/en/how-to/edit-cookies-chrome/) — the workflow EditThisCookie used to provide --- [^1]: EditThisCookie's install count was publicly displayed on its Chrome Web Store listing prior to removal; the often-quoted multi-million figure traces to Web Archive snapshots of the listing in 2023-2024 and is approximate. We have not independently verified the peak number. [^2]: The maintainer-account transfer and subsequent monetization changes were discussed across the developer community in September 2024. The original author addressed the situation publicly on his personal channels. [^3]: Chrome's Manifest V3 transition timeline is published at https://developer.chrome.com/docs/extensions/develop/migrate and the stable-channel MV2 disablement schedule at https://developer.chrome.com/blog/resuming-the-transition-to-mv3. ### concepts/en/what-is-a-cookie.md --- title: 'What is a cookie? Browser cookies explained (2026 guide)' slug: what-is-a-cookie description: 'A cookie is a small piece of data a website stores in your browser. Complete guide to browser cookies — types, attributes, SameSite, third-party deprecation, CHIPS, and how to manage them in 2026.' type: concept locale: en cluster: concept author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-05-22 primaryKeyword: what is a cookie secondaryKeywords: - browser cookies explained - cookie definition - how do cookies work - types of cookies - first-party vs third-party cookies - session cookie vs persistent cookie - SameSite cookie attribute - HttpOnly Secure cookie flags - third-party cookie deprecation - CHIPS partitioned cookies intent: informational funnel: tofu schemaType: - DefinedTerm - Article - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What is a cookie in simple terms? a: A cookie is a small text file — usually a few hundred bytes — that a website stores in your browser. The browser sends the cookie back to that same website on every subsequent request, which lets the site remember things like your login state, language preference, or shopping cart between page loads and visits. - q: Are cookies dangerous or viruses? a: No. A cookie is a passive text record, not an executable. It cannot install software, read files outside the browser's cookie store, or run code by itself. The privacy risk from cookies is about tracking and session theft, not malware. Third-party cookies enable cross-site tracking; stolen session cookies can let an attacker impersonate you on a site where you are logged in. - q: What is the difference between first-party and third-party cookies? a: A first-party cookie is set by the website whose address is in your URL bar (the site you are visiting). A third-party cookie is set by a different domain whose script or image is embedded in that page — usually an ad network, analytics service, or social widget. Browsers are progressively restricting third-party cookies because they are the main mechanism for cross-site tracking. - q: What is a session cookie vs a persistent cookie? a: A session cookie has no Expires or Max-Age attribute and is deleted when the browser session ends — typically when you close the browser. A persistent cookie has an explicit Expires date in the future and survives across browser sessions until that date, until you delete it manually, or until an auto-cleanup tool removes it. - q: What does the SameSite attribute do? a: SameSite controls whether the browser sends a cookie on cross-site requests. SameSite=Strict means the cookie is only sent on same-site requests. SameSite=Lax (the modern default in Chrome since 2020) sends the cookie on same-site requests plus top-level cross-site GET navigations. SameSite=None sends the cookie on any cross-site request and requires Secure. SameSite is the browser's primary defense against CSRF and cross-site cookie tracking. - q: What is HttpOnly and why does it matter? a: HttpOnly is a cookie flag that hides the cookie from JavaScript running in the page. document.cookie cannot read or modify an HttpOnly cookie. The flag is the browser's primary defense against session-cookie theft via XSS — even if an attacker injects script into your page, they cannot read an HttpOnly session cookie. - q: Are third-party cookies being phased out? a: Yes, gradually. Safari and Firefox already block third-party cookies by default. Chrome announced multiple phase-out timelines and as of 2024 settled on a user-choice model with the Privacy Sandbox APIs as the proposed replacement for ad-targeting and measurement. CHIPS (Cookies Having Independent Partitioned State) lets a site explicitly opt third-party cookies into per-top-site partitioning so they survive without enabling cross-site tracking. - q: How do I view, edit, or delete cookies in my browser? a: In Chrome, open DevTools (F12) → Application → Storage → Cookies to view and edit them; open Settings → Privacy and security → Cookies to delete them in bulk. For repeatable workflows install a Manifest V3 extension like CookieVault Editor. See our step-by-step guides for delete, edit, and export cookie tasks. - q: What is the maximum size or number of cookies? a: RFC 6265 recommends browsers support at least 4,096 bytes per cookie (name plus value combined) and at least 50 cookies per domain. Chrome and Firefox enforce roughly 4 KB per cookie and around 180 cookies per domain in practice. Try to keep cookie payloads small — large cookies are sent on every request to the matching domain, which adds latency. --- # What is a cookie? Browser cookies explained > **TL;DR**: A cookie is a small piece of data — typically a few hundred bytes — that a website stores in your browser to remember information between requests. Cookies power logins, shopping carts, and analytics; they also enabled the cross-site tracking era that browsers are now winding down. A cookie is a name-value text record that a website sets in your browser via the `Set-Cookie` HTTP response header, and that the browser automatically attaches to subsequent requests to the same domain through the `Cookie` request header. Cookies are the original mechanism for state on an otherwise stateless HTTP web — they predate localStorage, IndexedDB, service workers, and every modern client-storage alternative. Every cookie you have ever encountered, from "stay signed in" to the EU consent banner asking about them, is governed by this single small protocol[^1]. ## How cookies work > **In short**: Cookies are a thin layer on top of HTTP. The server sets one with a `Set-Cookie: name=value` response header; the browser stores it in a per-domain cookie jar; on every subsequent matching request the browser sends `Cookie: name=value` back. There is no client-side handshake — the browser obeys the server's directives within the constraints of RFC 6265. The cookie mechanism is widely credited to Lou Montulli, a Netscape engineer, who introduced it in 1994 to solve "remember the shopping cart between pages" for the e-commerce client MCI Net[^2]. Three decades later the underlying protocol is essentially unchanged. The formal specification is IETF RFC 6265[^1], with an active revision in IETF drafts[^3] that tightens the security and privacy boundaries. A minimal cookie exchange looks like this: ```http # Server response HTTP/1.1 200 OK Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax # Subsequent client request to the same site GET /account HTTP/1.1 Cookie: sid=abc123 ``` The browser does not interpret the value `abc123` — it is opaque to the browser. The server interprets it (typically as a database session key). The browser's job is to decide which cookies to attach to each request based on the cookie's `Domain`, `Path`, `Secure`, `SameSite`, and expiry attributes. > **Key point**: A cookie is set by the **server**, stored by the **browser**, and read by the **server** on every subsequent matching request. The browser is the courier, not the author. ## Anatomy of a cookie > **In short**: A cookie has one mandatory part (`name=value`) and seven attributes the server can set: `Domain`, `Path`, `Expires`, `Max-Age`, `Secure`, `HttpOnly`, and `SameSite`. Each attribute narrows or restricts when the browser sends the cookie back. The full attribute set defined by RFC 6265[^1] and its bis revision[^3]: - **Name and Value** — the only mandatory pair. ASCII text. Together must fit in roughly 4 KB[^4]. - **Domain** — defaults to the host that sent `Set-Cookie`. Setting `Domain=example.com` makes the cookie apply to `example.com` and all subdomains. - **Path** — defaults to the request path's directory. Setting `Path=/account` scopes the cookie to URLs under `/account`. - **Expires / Max-Age** — date or duration. Omitting both makes the cookie a session cookie (deleted when the browser session ends). `Max-Age=0` deletes the cookie immediately. - **Secure** — when set, the browser only sends the cookie over HTTPS. Plain-HTTP requests do not see it. - **HttpOnly** — when set, JavaScript in the page cannot access the cookie via `document.cookie`. The primary defense against session-cookie theft through XSS. - **SameSite** — Strict / Lax / None. Governs cross-site request behavior (covered below). - **Priority** (Chrome-specific extension) — Low / Medium / High. Hints to the browser which cookies to evict first when the per-domain cookie jar is full. ## Types of cookies > **In short**: Cookies are classified along two orthogonal axes — lifetime (session vs persistent) and origin (first-party vs third-party). A single cookie always has one value on each axis. Privacy regulations and browser settings then layer on a usage-based category system (strictly necessary / functional / analytics / advertising) that you see on consent banners. Six common categories users and regulators talk about, mapped onto the underlying protocol: | Category | Lifetime | Origin | Typical use | Browser default policy (2026) | | ----------------------- | ---------- | ----------- | ----------------------------------------- | ----------------------------------------------------- | | Session cookie | Session | First-party | Login session, current cart | Allowed by default | | Persistent first-party | Persistent | First-party | "Remember me", language preference | Allowed by default | | Strictly necessary | Either | First-party | Auth, fraud prevention | No consent required (GDPR) | | Functional / preference | Persistent | First-party | UI theme, font size | Consent recommended (GDPR) | | Analytics first-party | Persistent | First-party | First-party analytics | Consent required in EU | | Third-party advertising | Persistent | Third-party | Ad targeting, retargeting, cross-site IDs | Blocked in Safari / Firefox; restricted in Chrome[^5] | The Information Commissioner's Office (UK) summarizes the distinction succinctly[^6]: > Strictly necessary cookies are those that are essential to provide an online service requested by the user. Most other cookies require informed consent before they are set. ## What cookies are used for > **In short**: At the protocol level a cookie is generic name-value storage. In practice, the web uses cookies for six distinct jobs, in roughly decreasing order of how much they matter to user experience. The six dominant cookie use cases on the modern web: 1. **Authentication and session management** — a session ID cookie that tells the server which logged-in user a request belongs to. Almost always `HttpOnly`, `Secure`, `SameSite=Lax` or `Strict`. 2. **CSRF protection tokens** — a random anti-forgery value the server checks on state-changing requests. Usually paired with a hidden form field. 3. **Shopping cart and unfinished work** — preserving cart contents and form drafts across page loads. Often a single ID pointing at server-side state. 4. **User preferences** — language, theme, layout density, accessibility settings. Small persistent cookies with `Max-Age` of months to years. 5. **First-party analytics** — visitor identification and session timing for products like Plausible, Fathom, or self-hosted PostHog (when configured cookie-based). 6. **Advertising and cross-site tracking** — third-party cookies set by ad networks, retargeters, and analytics platforms that need to identify the same user across multiple sites. This is the category browsers are actively winding down. For developers, the practical implication is that most cookies you set should be first-party, scoped to the current site, marked `HttpOnly` and `Secure`, and given `SameSite=Lax` unless you have a specific cross-site flow that needs `None`. ## SameSite, HttpOnly, Secure — the three security attributes > **In short**: Three cookie attributes — `SameSite`, `HttpOnly`, and `Secure` — defend against three different attack classes. Setting all three correctly is the single highest-leverage cookie-security improvement a server can make. These three attributes form the modern cookie-security baseline. Each defends against a specific attack class: - **`Secure`** defends against passive network sniffing. The browser refuses to send the cookie over plain HTTP. Required on any cookie that holds session state, since session theft over an open Wi-Fi network is otherwise trivial. - **`HttpOnly`** defends against XSS-driven session theft. JavaScript injected into the page via a cross-site-scripting vulnerability cannot read an `HttpOnly` cookie via `document.cookie`. The server still sees it; the attacker's script does not. - **`SameSite`** defends against CSRF and cross-site tracking. Three values: - `SameSite=Strict` — the cookie is only sent on same-site requests. Maximum protection; sometimes inconvenient (a user clicking from another site to your domain will appear logged-out on the first request). - `SameSite=Lax` — the cookie is sent on same-site requests plus top-level cross-site GET navigations (link clicks). The modern Chrome default since 2020[^7]. - `SameSite=None` — the cookie is sent on every cross-site request. Required for legitimate third-party cookies (single sign-on, embedded payment widgets). Must be paired with `Secure`. Google's web.dev guidance is explicit on the priority order[^7]: "If you only do one thing today, set `SameSite=Lax` on every session cookie." ## First-party vs third-party cookies and the deprecation story > **In short**: A first-party cookie is set by the site in the URL bar; a third-party cookie is set by another domain whose code runs on that site. Third-party cookies built the modern ad-tracking economy, and modern browsers are systematically restricting or eliminating them. The third-party cookie wind-down is the most consequential change to the cookie ecosystem since the protocol was created. Status by browser as of mid-2026: - **Safari** — third-party cookies have been blocked by default since Intelligent Tracking Prevention (ITP) shipped in Safari 11 (2017), with successive tightenings. - **Firefox** — third-party cookies are partitioned by default under Total Cookie Protection (TCP) since 2022, effectively eliminating cross-site tracking. - **Chrome** — after multiple postponements of full third-party cookie deprecation[^5], settled on a user-choice approach with Privacy Sandbox APIs as the proposed replacement for ad targeting, attribution, and fraud prevention. For legitimate cross-site use cases (federated login, embedded checkout iframes), the modern alternative is **CHIPS — Cookies Having Independent Partitioned State**[^8]. A cookie with the `Partitioned` attribute is stored in a separate jar per top-level site, so the same iframe loaded under two different parent sites cannot read the same cookie. CHIPS preserves the legitimate "remember settings inside this widget" use case while breaking the cross-site identifier flow. If you maintain a service that depends on third-party cookies today, the immediate work is auditing your cookies for which ones need cross-site visibility (use CHIPS) versus which were tracking by design (rebuild on Privacy Sandbox or first-party data). ## How to view, edit, and delete cookies > **In short**: Every modern browser lets you view cookies through Settings or DevTools. For repeatable workflows — debugging session bugs, exporting cookies as test fixtures, auditing what a site stored — a Manifest V3 extension like CookieVault Editor is the standard tool. The eight-step inspection workflow below works on every Chromium browser. Eight-step quick reference for viewing and editing cookies in Chrome (Edge, Brave, Opera, Vivaldi, Arc work identically; Firefox is similar with a different menu layout): 1. Open the target site in a tab. 2. Press `F12` to open DevTools. 3. Click the **Application** tab. 4. In the left sidebar under **Storage**, click **Cookies**. 5. Click the domain to see all cookies in scope. 6. Double-click a cell (Value, Expires, SameSite, etc.) to edit it in place. 7. Press `Enter` to commit the edit; the browser applies it immediately. 8. Reload the page to send the modified cookie on the next request. For deleting cookies in bulk, the [Chrome cookie deletion guide](/en/how-to/delete-cookies-chrome/) covers three methods. To keep logins while clearing trackers see [clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/). For one-click repeatable edits across many sites, [CookieVault Editor](/en/editor/) is the open-source Manifest V3 tool we maintain. ## Common misconceptions about cookies A short cleanup of statements you may have seen on the internet that are not true: - **"Cookies are viruses"** — false. A cookie is a passive text record. It cannot install software, run code, or access files outside the browser's cookie store. - **"Cookies store your password"** — almost always false. A login cookie holds a session ID, not a password. The password is sent once to the server, hashed, and the server returns a session ID cookie. The password itself is not in the cookie. - **"Disabling cookies makes you anonymous"** — false. Browsers are fingerprintable through many other channels (User-Agent, screen resolution, fonts, WebGL hashes, IP address) that do not depend on cookies. - **"All cookies track you across sites"** — false. First-party cookies set by the site you are visiting do not see you on other sites. Cross-site tracking is specifically a third-party cookie concern. - **"Cookies are illegal under GDPR"** — false. Cookies are legal. What GDPR (and the ePrivacy Directive) regulate is the _consent_ requirement for non-essential cookies. Strictly necessary cookies do not require consent. - **"Clearing cookies fixes every browser issue"** — partially true. Clearing cookies will reset session and preference state. It will not fix cached resources, service worker bugs, or extension conflicts. ## See also - [How to delete cookies in Chrome](/en/how-to/delete-cookies-chrome/) - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) - [How to edit cookies in Chrome](/en/how-to/edit-cookies-chrome/) - [How to export cookies to JSON](/en/how-to/export-cookies-json/) - [CookieVault Editor](/en/editor/) — the open-source Manifest V3 cookie manager - [CookieVault Guardian](/en/guardian/) — auto-delete cookies on tab close --- [^1]: The current IETF specification is RFC 6265 — "HTTP State Management Mechanism," available at https://datatracker.ietf.org/doc/html/rfc6265. This document defines the `Set-Cookie` and `Cookie` headers, the cookie attribute semantics, the storage model, and the cookie matching rules. [^2]: The Mozilla Developer Network's HTTP cookies reference at https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies summarizes the modern cookie attribute set and the browser-side processing rules. The 1994 origin story is widely cited across web-history sources and traces to Lou Montulli's work at Netscape on a "shopping basket" feature. [^3]: The active revision of the cookie specification is "RFC 6265bis" — formally draft-ietf-httpbis-rfc6265bis — published in the IETF HTTP working group at https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/. It tightens prefix rules (`__Host-`, `__Secure-`), formalizes `SameSite`, and refines partitioning semantics. [^4]: The 4 KB per-cookie and 50-cookies-per-domain figures are RFC 6265 §6.1 recommendations. Real-world browser limits are roughly twice the recommended minimum but vary by browser; the Chrome team's `chrome.cookies` API reference at https://developer.chrome.com/docs/extensions/reference/api/cookies documents the practical Chrome limits. [^5]: Chrome's third-party cookie position has shifted multiple times. The current approach is documented under Privacy Sandbox at https://developer.chrome.com/docs/privacy-sandbox/. Status pages and individual API documentation under that root track ongoing changes. [^6]: The UK Information Commissioner's Office (ICO) publishes practical guidance on cookies and consent under the Privacy and Electronic Communications Regulations (PECR). The ICO has restructured this guidance page several times and the URL is unstable; search "ICO PECR cookies guidance" or start from https://ico.org.uk and navigate to "For organisations → Online tracking". The "strictly necessary" definition paraphrased in the table commentary above follows the ICO formulation. [^7]: Google's web.dev primer "SameSite cookies explained" at https://web.dev/articles/samesite-cookies-explained is the canonical practitioner-facing reference for `SameSite` defaults and the Chrome rollout history. [^8]: The CHIPS specification — "Cookies Having Independent Partitioned State" — is documented at https://developer.chrome.com/docs/privacy-sandbox/chips. CHIPS lets a cross-site cookie opt into per-top-site partitioning so it survives third-party-cookie blocking without enabling cross-site tracking. ### features/en/auto-delete-on-tab-close.md --- title: 'Auto-delete cookies on tab close — CookieVault Guardian' slug: auto-delete-on-tab-close description: 'CookieVault Guardian auto-deletes cookies, localStorage, IndexedDB, Cache, and Service Workers when you close a tab. Whitelist-exempt, Manifest V3, the Cookie AutoDelete successor.' type: feature locale: en cluster: tool author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: auto delete cookies on tab close secondaryKeywords: - cookie autodelete chrome - clear cookies when tab closes - manifest v3 cookie cleaner - automatically clear browser storage - per domain cookie cleanup - whitelist exempt cookie deletion intent: commercial funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What exactly gets deleted when I close a tab? a: When the last tab on a domain closes, CookieVault Guardian deletes that domain's cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations — unless the domain is whitelisted. Each storage type has its own toggle in settings, so you can narrow the scope if a specific site needs one of them preserved. - q: When does the deletion actually fire? a: Guardian watches for tab-close events and checks whether any other tab is still open on the same domain. Only when the last tab for that domain closes does cleanup run, so closing one of three open tabs on a site does not wipe your session out from under the other two. Whitelisted domains are skipped entirely. - q: Will this break sites I stay logged into? a: Only if you have not whitelisted them. Auto-delete is aggressive by design — that is the privacy benefit — so the workflow is to whitelist the handful of sites you want to stay logged into and let everything else clean automatically. Subdomain inheritance means one whitelist entry usually covers a whole service. - q: How is this different from Cookie AutoDelete? a: Guardian is the Manifest V3 successor to Cookie AutoDelete, which Chrome force-disabled in late 2024 with the MV2 sunset. It matches Cookie AutoDelete's whitelist, greylist, and wildcard model, then extends cleanup from cookies-only to every browser-storage API, including IndexedDB, Cache Storage, and Service Workers — surfaces the original did not fully cover. - q: Does it clear my saved passwords? a: No. Saved passwords live in the browser's password manager, a separate subsystem from the cookie and site-storage APIs Guardian cleans. Closing a tab clears the targeted storage for that domain and never touches the password manager entry, so your stored logins remain available for the next visit. - q: Can I undo a cleanup? a: For cookies, the Pro tier keeps 90 days of history with one-click restore. For other storage types — localStorage, IndexedDB, Cache Storage — cleanup is irreversible once it runs. The correct protection for high-value client-side state is the whitelist, not the history; whitelist anything you cannot afford to lose. - q: Is auto-delete free? a: Yes. The full cleanup engine, all six storage types, up to 10 local Guardian rules, greylist, and wildcard patterns are permanently free. The Pro tier ($3.99/month or $29/year) adds end-to-end encrypted cross-device whitelist sync and 90-day cookie history with undo. The core privacy feature costs nothing. - q: Does it work in Firefox as well as Chrome? a: Yes. Guardian ships a Chrome Web Store build for Chromium browsers and a separate build for Firefox. Cookie AutoDelete still works on Firefox because Firefox kept Manifest V2 support; on Chromium browsers, where Cookie AutoDelete was disabled, Guardian is the path forward. Cross-browser whitelist sync is the reason to choose Guardian even on Firefox. --- # 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[^1]. 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[^2], 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[^3] rather than any private mechanism, which is part of why the behavior is predictable across browsers. | Behavior | CookieVault Guardian | Cookie AutoDelete (MV2) | | ------------------------------- | -------------------- | ------------------------ | | Manifest version | V3 | V2 (deprecated) | | Chrome / Edge / Brave | Yes | No (disabled) | | Firefox | Yes | Yes | | Cleans cookies | Yes | Yes | | Cleans localStorage | Yes | Partial (later versions) | | Cleans IndexedDB | Yes | No | | Cleans Cache Storage | Yes | No | | Cleans Service Workers | Yes | No | | Whitelist / greylist / wildcard | Yes | Yes | | Cross-device whitelist sync | Yes (Pro) | No | The detailed migration walk-through, including how to import an existing rule set, lives on the [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/) 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](/en/features/cookie-whitelist/) page. ## Free vs Pro > **In short**: All cleanup, all storage types, and up to 10 local Guardian rules are free forever. Pro ($3.99/month or $29/year) adds encrypted cross-device whitelist sync and 90-day cookie history with undo. | Capability | Free | Pro ($3.99/mo or $29/yr) | | ------------------------------- | -------- | ------------------------ | | Auto-delete (six storage types) | Yes | Yes | | Local Guardian rules | Up to 10 | Unlimited | | Greylist and wildcards | Yes | Yes | | Cross-device whitelist sync | No | Yes | | 90-day cookie history with undo | No | Yes | 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](/en/features/encrypted-cloud-sync/) page. ## How to set it up 1. **Install CookieVault Guardian** from the [download page](/en/download/) 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](/en/how-to/auto-delete-on-tab-close/). ## See also - [CookieVault Guardian](/en/guardian/) — the extension this feature powers - [Cookie whitelist](/en/features/cookie-whitelist/) — the exemption list deep dive - [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/) — full migration guide and feature matrix - [Auto-delete on tab close how-to](/en/how-to/auto-delete-on-tab-close/) — step-by-step setup - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) — the whitelist-driven workflow - [Pricing](/en/pricing/) — Free / Pro / Team breakdown --- [^1]: Chrome's Manifest V2 deprecation and migration timeline, which disabled Cookie AutoDelete on Chromium, is documented at https://developer.chrome.com/docs/extensions/develop/migrate. [^2]: Cookies as one of several client-side storage mechanisms, alongside other site storage, are documented by MDN at https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies. [^3]: Guardian removes cookies through the official browser cookie API documented at https://developer.chrome.com/docs/extensions/reference/api/cookies, the same store the browser reads from. ### features/en/cookie-whitelist.md --- title: 'Cookie whitelist — Keep the sites you actually use' slug: cookie-whitelist description: 'CookieVault cookie whitelist is a per-domain allowlist with subdomain inheritance, wildcards, and a greylist. Keep logins for trusted sites while auto-deleting everything else.' type: feature locale: en cluster: tool author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookie whitelist chrome secondaryKeywords: - cookie allowlist - keep cookies for specific sites - cookie whitelist subdomain - wildcard cookie rules - cookie greylist - exempt sites from cookie deletion intent: commercial funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What is the cookie whitelist? a: The whitelist is a per-domain allowlist that exempts trusted sites from CookieVault Guardian's auto-delete. Whitelisted domains keep their cookies, localStorage, and other site data across tab closes; every other domain is cleaned the moment its last tab closes. It is the single setting that turns aggressive auto-delete from annoying into useful. - q: How do I add a site to the whitelist? a: Visit the site, click the CookieVault toolbar icon, and choose "Add to whitelist." That adds the current domain with subdomain inheritance on by default, so one entry typically covers the whole service. You can also add or edit entries manually under Settings, including wildcard patterns for advanced cases. - q: Does whitelisting a domain cover its subdomains? a: Yes, by default. Subdomain inheritance means a single example.com entry also exempts mail.example.com, app.example.com, and so on. You can turn inheritance off for a stricter, exact-host match if you want to whitelist only the apex domain and clean its subdomains. - q: What is the difference between the whitelist and the greylist? a: The whitelist means "never clean — keep across sessions." The greylist is a middle ground meaning "keep for the current session, then clean or auto-promote on the next close." Use the whitelist for sites you stay logged into permanently, and the greylist for a one-off visit where you want continuity now but no long-term persistence. - q: Can I use wildcards? a: Yes. A pattern like *.googleapis.com whitelists every subdomain of googleapis.com in one rule, which is handy for API hosts and CDNs that use many subdomains. Wildcards keep the list short and stable instead of forcing you to add dozens of near-identical entries. - q: Is the whitelist free? a: The local whitelist is permanently free with up to 10 local rules, including greylist and wildcard support. The Pro tier ($3.99/month or $29/year) adds end-to-end encrypted cross-device whitelist sync, so the same rule set follows you across Chrome, Edge, Firefox, and your other browsers. - q: Will the whitelist keep me logged in after I close the tab? a: Yes — that is its purpose. A whitelisted domain's cookies, including its session cookie, are preserved when the tab closes, so reopening the site finds you still logged in. Non-whitelisted domains have their session cookies cleaned, which logs you out of them as intended. - q: How is the whitelist synced across devices? a: Whitelist sync is a Pro feature and rides the same zero-knowledge crypto as the rest of CookieVault — the rule set is encrypted on-device with a passphrase-derived key, and the sync server stores only opaque ciphertext. Your list of trusted sites is private even from us. - q: What should be on my whitelist to start? a: A practical starter list is your primary email, your code host, your main work tools, your bank, and your password manager's web UI. Those are the sites you almost certainly want to stay logged into; everything else can clean on tab close until you decide otherwise. --- # Cookie whitelist > **TL;DR**: The CookieVault cookie whitelist is a per-domain allowlist that exempts trusted sites from auto-delete — so you keep logins for the sites you use daily while everything else is cleaned on tab close. Subdomain inheritance, wildcards, and a greylist keep the list short; the local list is free, and cross-device sync is Pro. The cookie whitelist in CookieVault Guardian is a per-domain allowlist that overrides auto-delete behavior, so whitelisted origins keep their cookies and site data across tab closes while every other domain is cleaned the moment its last tab closes. It is the modern reimplementation of the classic Cookie AutoDelete allowlist model, extended with subdomain inheritance, wildcard patterns, and a greylist for session-only sites. In practice the whitelist is the most important setting in the whole product: it is the single dial that decides which logins survive and which disappear. ## How the whitelist works > **In short**: Add a domain by clicking the toolbar icon on the site. Subdomain inheritance is on by default, so one entry covers a whole service. Whitelisted domains are simply skipped when auto-delete runs after the last tab closes. Cookies are how sites remember you between requests; MDN documents that the session cookie is what keeps you authenticated[^1]. The whitelist works by telling Guardian to leave a domain's cookies — and its session cookie specifically — in place when cleanup would otherwise fire. CookieVault reads and preserves those records through the official browser cookie API[^2], so a whitelisted login behaves exactly as it would with no extension installed. Six mechanics that make the list manageable: - **One-click add** — click the toolbar icon on any site and choose "Add to whitelist" - **Subdomain inheritance (default on)** — `example.com` also exempts `mail.example.com` and `app.example.com` - **Exact-host mode** — turn inheritance off to whitelist only the apex and clean its subdomains - **Wildcards** — `*.googleapis.com` covers every subdomain of an API or CDN host in one rule - **Greylist** — session-only exemption that cleans or auto-promotes on the next close - **Unlimited locally** — no cap on entries in the free, local list A reliable principle for allowlists is to keep them short and intentional: a small, well-chosen list is easy to reason about, while a sprawling one quietly defeats the privacy goal. ## Whitelist vs greylist > **In short**: Whitelist means "never clean, keep across sessions." Greylist means "keep for this session, then clean or auto-promote on the next close." Use the whitelist for permanent logins and the greylist for one-off visits. | Behavior | Whitelist | Greylist | Default (neither) | | ---------------------------- | ---------------- | -------------------------- | ----------------- | | Cookies kept across sessions | Yes | Current session only | No | | Cleaned on last-tab close | Never | On next close (or promote) | Always | | Stay logged in after reopen | Yes | Until session ends | No | | Best for | Daily-use logins | One-off / temporary visits | Untrusted sites | | Subdomain inheritance | Yes (default) | Yes | n/a | The greylist exists because real browsing is not binary. Sometimes you want continuity for the next hour on a site you will never return to — the greylist gives you that without permanently growing your whitelist. ## Common whitelist mistakes > **In short**: The two failure modes are whitelisting too much (which quietly cancels the privacy benefit) and forgetting the federated-login domain a site depends on (which logs you out anyway). A short, deliberate list and an awareness of identity-provider domains fix both. Six mistakes that trip up new users, and how to avoid each: - **Whitelisting everything "just in case"** — a bloated list means almost nothing ever cleans; whitelist only what you genuinely stay logged into - **Forgetting the identity provider** — a site that authenticates through `accounts.google.com` or an SSO host needs that provider domain whitelisted too, or the login still breaks - **Whitelisting the apex but needing a subdomain** — confirm subdomain inheritance is on, or add the specific subdomain - **Over-broad wildcards** — `*.com` is not a rule; scope wildcards to a single service such as `*.googleapis.com` - **Treating the greylist as permanent** — greylisted sites still clean on the next close, so move long-term logins to the real whitelist - **Whitelisting a site to recover client-side state** — the whitelist prevents future cleanup; it cannot restore data already deleted The single most common support question is "why did this site log me out even though I whitelisted it?" — and the answer is almost always a missing federated-login or SSO domain. When in doubt, whitelist both the app domain and whichever account host the login redirects through. ## How CookieVault compares to a manual approach > **In short**: You could manually clear cookies and re-login, or use the browser's per-site cookie settings, but neither gives you a one-click, syncable, wildcard-capable allowlist tied to automatic tab-close cleanup. | Approach | One-click add | Wildcards | Auto-clean rest | Cross-device sync | | -------------------------------- | ------------- | --------- | --------------- | ------------------- | | CookieVault whitelist | Yes | Yes | Yes | Yes (Pro) | | Browser per-site cookie settings | No | No | No (manual) | Tied to one browser | | Manual clear + re-login | No | No | No | No | | Cookie AutoDelete (MV2) | Yes | Yes | Yes | No | The honest note: the browser's own per-site cookie controls are perfectly fine if you only ever care about a couple of sites and never switch browsers. The whitelist earns its keep when you want automatic cleanup of everything you did not explicitly trust, plus the same rules on every device. ## Free vs Pro > **In short**: The local whitelist — unlimited entries, greylist, wildcards — is free forever. Pro ($3.99/month or $29/year) adds encrypted cross-device sync so your trusted-sites list follows you everywhere. | Capability | Free | Pro ($3.99/mo or $29/yr) | | ------------------------------ | -------- | ------------------------ | | Local Guardian rules | Up to 10 | Unlimited | | Subdomain inheritance | Yes | Yes | | Wildcards and greylist | Yes | Yes | | Cross-device whitelist sync | No | Yes | | Encrypted, zero-knowledge sync | n/a | Yes | Sync is the only paid part, and it uses the same zero-knowledge stack described on the [encrypted cloud sync](/en/features/encrypted-cloud-sync/) page — your list of trusted sites is encrypted on-device and the server sees only ciphertext. See the [pricing page](/en/pricing/) for the full breakdown. ## How to build your whitelist 1. **Install CookieVault Guardian** from the [download page](/en/download/) and pin its toolbar icon 2. **Visit your primary email** (Gmail, Outlook, Proton) and click the icon → "Add to whitelist" 3. **Visit your code host** (GitHub, GitLab) and whitelist it the same way 4. **Whitelist your work tools** — the ones you stay logged into all day 5. **Whitelist your bank and your password manager's web UI** 6. **Add wildcards** for any API or CDN host that uses many subdomains, such as `*.googleapis.com` 7. **Greylist one-off sites** you want only for the current session 8. **Review the list** under Settings → Whitelist and trim anything you no longer need Everything not on the list cleans on tab close by default. For a guided version with screenshots and edge cases, see the [whitelist cookies how-to](/en/how-to/whitelist-cookies/). ## See also - [CookieVault Guardian](/en/guardian/) — the auto-delete extension the whitelist controls - [Auto-delete cookies on tab close](/en/features/auto-delete-on-tab-close/) — what happens to non-whitelisted sites - [Whitelist cookies how-to](/en/how-to/whitelist-cookies/) — step-by-step setup with edge cases - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) — the workflow the whitelist enables - [Encrypted cloud sync](/en/features/encrypted-cloud-sync/) — how whitelist sync stays zero-knowledge - [Pricing](/en/pricing/) — Free / Pro / Team breakdown --- [^1]: The role of the session cookie in keeping you authenticated between requests is documented by MDN at https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies. [^2]: CookieVault preserves and reads whitelisted cookies through the official browser cookie API documented at https://developer.chrome.com/docs/extensions/reference/api/cookies. ### features/en/encrypted-cloud-sync.md --- title: 'End-to-end encrypted cookie sync — Zero-knowledge cloud' slug: encrypted-cloud-sync description: 'CookieVault encrypted cookie sync uses Web Crypto API AES-256-GCM with PBKDF2-SHA-256-derived keys. Even our servers cannot read your cookies. A Pro, zero-knowledge feature.' type: feature locale: en cluster: privacy author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: encrypted cookie sync secondaryKeywords: - end to end encrypted cookies - zero knowledge cookie sync - Web Crypto API cookie encryption - pbkdf2 sha-256 key derivation - cross device cookie sync - private cookie backup intent: commercial funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What does "end-to-end encrypted" actually mean for cookie sync? a: It means encryption and decryption happen only on your own devices, never on the server. Your passphrase is run through PBKDF2-SHA-256 on-device to derive a key, each cookie record is sealed with AES-256-GCM before it leaves the browser, and the sync server only ever receives and stores opaque ciphertext. The server has no key, so it cannot read your cookies even if compelled to. - q: Can CookieVault staff read my synced cookies? a: No. This is the core of the zero-knowledge design. The encryption key is derived from your passphrase on your device and never transmitted. CookieVault staff, a malicious insider, a subpoena, or an attacker who fully compromises the sync server would all see the same thing — undecryptable ciphertext blobs. The plaintext exists only inside your browser, after you have unlocked it locally. - q: Which cryptographic primitives are used, and why? a: Key derivation uses PBKDF2-SHA-256 with 600,000 iterations. Record encryption uses AES-256-GCM through the browser-native Web Crypto API, with a fresh 96-bit IV per record. These are standard, reviewed primitives rather than custom cryptography. - q: What happens if I forget my passphrase? a: Your data is unrecoverable, by design. Because the server never holds your key, there is no "reset password" that can decrypt existing ciphertext. We can reset account access, but the previously synced cookies stay sealed forever. This is the unavoidable trade-off of true zero-knowledge encryption; we recommend storing your passphrase in a password manager. - q: Is encrypted sync free or Pro? a: Encrypted cross-device sync is a Pro feature ($3.99/month or $29/year). All local cookie management in CookieVault Editor and all local cleanup in Guardian remain permanently free. Sync is the one capability that requires server infrastructure, so it sits in the paid tier — but the crypto that protects it is the same regardless of price. - q: How is this different from Chrome's built-in sync? a: Chrome sync stores cookies and other data tied to your Google account, with Google holding the keys unless you set a separate sync passphrase, and it is bound to the Chrome ecosystem. CookieVault sync is zero-knowledge by default, works across Chrome, Edge, Brave, Firefox, and other supported browsers, and only syncs cookies and CookieVault settings — not your whole browsing profile. - q: Can I verify the encryption claims myself? a: Yes. The cryptographic boundary — key derivation, encryption, and the sync client — is open source under the MIT license on GitHub. You can read exactly which primitives are called, confirm the server only receives ciphertext, and reproduce the build. An independent third-party audit of the crypto stack is planned for Q3 2026. - q: Does sync slow down my browser or drain battery? a: Sync runs as a debounced background task, not on every keystroke. After an initial encrypted snapshot, only changed cookie records are re-encrypted and pushed, so steady-state traffic is small. Per-device subkeys let each browser unlock quickly without re-deriving the full PBKDF2-SHA-256 key on every sync cycle. --- # End-to-end encrypted cloud sync > **TL;DR**: CookieVault encrypted cookie sync uses Web Crypto API's AES-256-GCM with PBKDF2-SHA-256-derived keys. Your cookies are encrypted on the device before leaving the browser, and the sync server stores only opaque ciphertext — ciphertext that even CookieVault engineers cannot decrypt. It is a Pro, zero-knowledge feature. End-to-end encrypted cookie sync is a zero-knowledge mechanism that keeps your cookies in lockstep across devices while ensuring the cloud server stores nothing but undecryptable ciphertext. Your passphrase derives the encryption key on your own device using PBKDF2-SHA-256; that key never touches CookieVault infrastructure, which means neither our engineers, a server compromise, nor a legal demand can reveal your cookies. It is the Pro-tier backbone shared by both CookieVault Editor and CookieVault Guardian, and the cryptographic boundary is open source so the claim is verifiable rather than promised. ## How the encryption works > **In short**: Your passphrase is processed on-device with PBKDF2-SHA-256 (600,000 iterations) to produce a master key. Each cookie record is encrypted with AES-256-GCM through the Web Crypto API before leaving the browser. The pipeline uses standard, reviewed primitives rather than custom cryptography. PBKDF2-SHA-256 runs for 600,000 iterations to raise the cost of offline passphrase guessing. AES-256-GCM provides authenticated encryption with a fresh 96-bit IV for every record through the browser-native Web Crypto API. Six properties define the design: - **Client-side key derivation** — PBKDF2-SHA-256 turns your passphrase into a key on your device; the key is never transmitted or stored server-side - **Per-record encryption** — each cookie is individually sealed with AES-256-GCM, so a single corrupted blob never poisons the whole vault - **Authenticated ciphertext** — the AES-GCM authentication tag detects tampering, so a modified blob is rejected rather than silently decrypted into garbage - **Per-device subkeys** — each browser derives a fast-unlock subkey so it does not re-run the full PBKDF2-SHA-256 cost on every sync cycle - **Ciphertext-only storage** — the sync server persists opaque blobs plus minimal routing metadata, never plaintext - **Open cryptographic boundary** — the derivation, encryption, and sync-client code are public so the data path is auditable A widely held principle in applied cryptography is that you should encrypt before you upload, not trust the server to encrypt for you. That is exactly the boundary CookieVault enforces: the browser is the only place plaintext ever exists. ## The threat model > **In short**: We assume the server can be fully compromised and design so that it does not matter. Server breach, network interception, and a subpoena all reduce to "attacker has ciphertext." The one scenario that exposes plaintext is an attacker controlling your unlocked device — which no sync system can defend against. Cookies are bearer tokens: whoever holds a valid session cookie is, to the destination site, you. Browser documentation is explicit that cookies carry session identifiers and authentication state[^1], which is precisely why syncing them in plaintext to any third party would be reckless. The threat model treats that seriously. | Threat scenario | What the attacker sees | Outcome | | -------------------------- | ----------------------------- | ------------------------------------------------ | | Sync server fully breached | Opaque AES-256-GCM ciphertext | No usable cookies; no key on the server | | Network MITM | TLS-wrapped ciphertext | Double-protected; nothing to read | | Legal demand / subpoena | Stored ciphertext only | Nothing decryptable to hand over | | Malicious insider | Same ciphertext as everyone | Zero-knowledge means no privileged access exists | | Stolen, locked device | Encrypted local vault | Needs your passphrase to unlock | | Stolen, unlocked device | Plaintext after unlock | Out of scope — protect device-level access | The honest boundary is the last row: end-to-end encryption protects data in transit and at rest on the server, not an attacker who is already sitting at your unlocked browser. For that you rely on device login, full-disk encryption, and screen locks — defenses that live below the extension. ## Free vs Pro > **In short**: All local cookie work is free forever. Encrypted cross-device sync is the Pro feature ($3.99/month or $29/year) because it is the only capability that needs server infrastructure. The crypto protecting your data is identical regardless of tier. | Capability | Free | Pro ($3.99/mo or $29/yr) | | ------------------------------------ | ----------- | ------------------------ | | Local cookie view / edit / delete | Yes | Yes | | Local export (JSON / Netscape / HAR) | Yes | Yes | | Auto-delete on tab close (Guardian) | Yes | Yes | | Cross-device encrypted sync | No | Yes | | Cookie history with undo (90 days) | No | Yes | | Encrypted profile sync | No | Yes | | Zero-knowledge architecture | n/a (local) | Yes | Pro is only worth paying for if you use more than one device and want them to stay in sync, or if you want the safety net of cookie-history undo. A single-device, local-only user gets the entire core workflow for free. See the [pricing page](/en/pricing/) for the full Free / Pro / Team breakdown. ## How to set up encrypted sync 1. **Install CookieVault** (Editor, Guardian, or both) from the [download page](/en/download/) 2. **Open the extension popup** and click "Enable sync" 3. **Create a Pro account** with your email — this only handles billing and routing, never your key 4. **Choose a strong passphrase** and store it in a password manager; this is the only thing that can ever decrypt your data 5. **Confirm the on-device key derivation** runs (the popup shows "deriving key…" while PBKDF2-SHA-256 works) 6. **Wait for the first encrypted snapshot** to upload — all selected cookies are sealed before transmission 7. **Install CookieVault on a second device** and enter the same passphrase to derive the same key locally 8. **Verify the sync indicator** turns green on both devices; changed records now replicate as encrypted blobs If you ever change the passphrase, every device re-derives a new key and re-encrypts its local vault before the next push. There is no server-side re-encryption because the server has no key to use. ## Audit and verifiability > **In short**: The encryption code is open source and reproducible-built, so the data path is verifiable today. An independent third-party audit of the crypto stack is scheduled for Q3 2026, with the report and any findings published in full. Trust-me security is not security. Because the derivation, encryption, and sync-client code live in public MIT-licensed repositories, anyone can confirm that the key never leaves the device and that only ciphertext reaches the server. Chrome's extension model further constrains what an extension can touch[^2], and cookies are read and written through the official browser cookie API[^1] rather than any private channel. The planned external audit is meant to add a second, independent set of eyes; we will link the report from the [security page](/en/security/) when it lands. ## See also - [CookieVault Editor](/en/editor/) — the cookie editor that uses this sync engine - [CookieVault Guardian](/en/guardian/) — the auto-delete extension that shares the same Pro sync - [Security](/en/security/) — the full E2E encryption design and threat model - [Open source](/en/open-source/) — MIT license, public crypto boundary, reproducible builds - [Multi-account profiles](/en/features/multi-account-profiles/) — encrypted profile snapshots that sync the same way - [Pricing](/en/pricing/) — Free / Pro / Team breakdown --- [^1]: The browser cookie store, including session and authentication cookies, is documented by MDN at https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies. CookieVault reads and writes cookies only through the official browser cookie API. [^2]: The Chrome extensions cookies API and its permission model are documented at https://developer.chrome.com/docs/extensions/reference/api/cookies, which defines the only interface an extension may use to access the browser cookie store. ### features/en/multi-account-profiles.md --- title: 'Multi-account profiles — Switch cookie identities in one click' slug: multi-account-profiles description: 'CookieVault multi-account profiles are named, encrypted cookie snapshots. Switch between work, personal, and testing identities in one click — no logging out, one browser window.' type: feature locale: en cluster: tool author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: multi account cookie profile secondaryKeywords: - cookie profile switcher - browser identity switcher - switch accounts without logging out - multiple logins same site - work personal browser separation - encrypted cookie snapshot intent: commercial funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What is a multi-account profile in CookieVault? a: A profile is a named, encrypted snapshot of the cookies for the domains you choose. When you switch to a profile, CookieVault writes that snapshot back into the browser's cookie store before the next request, so the site sees a different logged-in identity. One profile might hold your work email and tools, another your personal accounts — all in a single browser window, no separate profiles or windows required. - q: How is this different from Chrome profiles or Firefox containers? a: Chrome profiles spin up an entirely separate browser instance with its own window, history, and extensions. Firefox Multi-Account Containers isolate cookies per tab but are Firefox-only. CookieVault profiles are lighter and cross-browser — they snapshot and swap only the cookies for chosen domains inside your current window, so switching identities does not mean opening a new browser or losing your tab layout. - q: Will switching profiles log me out of other sites? a: No. A profile only covers the domains you attach to it. Cookies for unrelated sites are left untouched when you switch. If you scope a profile to just your email and CRM domains, swapping that profile changes only those logins and leaves everything else exactly as it was. - q: Are my profiles encrypted? a: Yes. Each profile snapshot is stored as encrypted data, not as plaintext cookies sitting in a file. In the Pro tier, profiles also sync across devices using the same zero-knowledge stack as CookieVault sync — PBKDF2-SHA-256-derived keys and AES-256-GCM ciphertext, with the server holding only opaque blobs. - q: How many profiles can I have? a: The Free tier includes 1 named profile stored locally. Pro ($3.99/month or $29/year) unlocks unlimited profiles, one-click switching, and end-to-end encrypted cross-device sync. Team adds profile sharing for teammates. - q: Is this useful for QA and testing? a: Very. QA engineers can keep a profile per test persona — admin, free user, paid user, suspended user — and flip between them in one click to verify role-specific behavior, without maintaining separate browsers or constantly re-authenticating. Profiles can also be captured as fixtures for the cookie state a test needs. - q: Does switching profiles touch localStorage or just cookies? a: Profiles snapshot cookies, plus localStorage and sessionStorage for the chosen domains where the browser permits, so the restored identity is as complete as possible. Cookies are the primary session carrier and are always included; the extra storage types make the swap cleaner for sites that cache identity state client-side. - q: What happens to a profile if a session expires? a: A snapshot captures cookies as they were at save time, including session cookies. If the underlying session has since expired server-side, restoring the profile restores the cookie but the site may still require re-authentication. Re-saving the profile after logging back in refreshes the snapshot with the new valid session cookie. - q: Can I share a profile with a teammate? a: Profile sharing is a Team capability. Because profiles contain sensitive session state, sharing grants a teammate the ability to decrypt and load only the selected profile. Treat every shared profile as a shared credential. --- # Multi-account profiles > **TL;DR**: Multi-account profiles are named, encrypted cookie snapshots for work, personal, and testing identities. Free stores 1 local profile; Pro adds unlimited profiles, one-click switching, and encrypted cross-device sync. A multi-account profile in CookieVault is a named, encrypted snapshot of the cookies for the domains you choose, which you can load back into the browser in a single click to instantly become a different logged-in identity. It is the modern, Manifest V3-compatible alternative to juggling separate Chrome profiles or Firefox containers: instead of opening a new browser window per identity, CookieVault swaps only the relevant cookies in your current window. The result is that one browser session can flip between your work email and your personal email — or between an admin test account and a free-tier test account — without ever visiting a logout screen. ## How profiles work > **In short**: Each profile captures the cookies (plus localStorage and sessionStorage where allowed) for the domains you attach to it, encrypts the snapshot, and stores it under a name. Switching writes that snapshot back into the browser's cookie store before the next page load, so the site sees a fresh, complete identity. Cookies are the bearer tokens that tell a site who you are; MDN documents that session and authentication state is carried in cookies the browser sends with each request[^1]. CookieVault uses the official browser cookie API to read and restore those records[^2], so a profile swap is a clean write to the same store the browser already reads from — not a hack or an injection. Six things that make profiles practical day to day: - **Scoped to chosen domains** — a profile only owns the sites you attach, so switching never disturbs unrelated logins - **One-click activation** — pick a profile from the popup and the snapshot is restored before your next request - **Encrypted at rest** — snapshots are stored encrypted, not as plaintext cookie files - **Includes more than cookies** — localStorage and sessionStorage for chosen domains ride along where the browser allows - **Single-window operation** — no new browser profile, no new window, no lost tab layout - **Re-save anytime** — log in fresh, hit save, and the profile updates to the new valid session A common principle in identity tooling is that the cleanest switch is the one that touches the least state. Profiles follow that: change only the cookies that define the identity, leave the rest of the browser alone. ## How profiles compare > **In short**: Chrome profiles are heavyweight separate browsers; Firefox containers are tab-scoped but Firefox-only. CookieVault profiles are lightweight, cross-browser, encrypted snapshots that swap in your current window. | Approach | New window? | Cross-browser? | Encrypted? | One-click swap? | | --------------------------- | ------------ | -------------- | ---------- | ------------------- | | CookieVault profiles | No | Yes | Yes | Yes | | Chrome browser profiles | Yes | No (Chromium) | n/a | No (relaunch) | | Firefox containers | No (per tab) | No (Firefox) | No | Partial | | Incognito / private mode | New window | Per browser | n/a | No (no persistence) | | Manual cookie clear + login | No | n/a | n/a | No (re-auth) | The trade-off is honest: Chrome profiles also isolate history, extensions, and bookmarks, which CookieVault deliberately does not touch. If you need full environment isolation, a Chrome profile is the right tool. If you need fast identity switching for the same set of sites without leaving your window, profiles win. ## Who profiles are for > **In short**: Anyone who logs into the same sites as more than one identity — QA engineers cycling test personas, developers comparing logged-in versus anonymous views, and privacy-minded users keeping work and personal accounts apart. Three core audiences: - **QA engineers** keeping a profile per role (admin, paid, free, suspended) and flipping between them to verify role-specific behavior without re-authenticating each time - **Developers** comparing logged-in versus anonymous experiences, or testing multi-tenant apps as different tenant accounts back to back - **Privacy-conscious users** keeping a hard wall between a work identity and a personal identity on the same services, without trusting the site's own account switcher If you have ever opened an incognito window just to log into a second account, profiles replace that habit with something persistent and one-click. ## Free vs Pro > **In short**: Free includes 1 local profile. Pro ($3.99/month or $29/year) unlocks unlimited profiles, one-click switching, and end-to-end encrypted cross-device sync. Team adds profile sharing. | Capability | Free | Pro ($3.99/mo or $29/yr) | | --------------------------- | ---- | ------------------------ | | Named profiles | 1 | Unlimited | | One-click switching | Yes | Yes | | Encrypted at rest | Yes | Yes | | Cross-device profile sync | No | Yes | | Profile sharing (teammates) | No | No (Team only) | | Scope per domain | Yes | Yes | Pro is worth it when one local profile is not enough or when you want the same profiles on every device; profile sharing is reserved for Team. See the [pricing page](/en/pricing/) for the complete breakdown. Profile sync rides the same zero-knowledge crypto described on the [encrypted cloud sync](/en/features/encrypted-cloud-sync/) page. ## How to create and switch profiles 1. **Open the CookieVault popup** on a site you want to capture 2. **Click "New profile"** and give it a clear name, such as "Work email" or "QA admin" 3. **Choose the domains** the profile should cover (the current site is pre-selected) 4. **Log in as the identity you want to capture** if you are not already 5. **Click "Save snapshot"** — CookieVault encrypts the current cookies for those domains under the profile name 6. **Repeat** to create your second identity, for example "Personal email," capturing its own logged-in cookies 7. **Switch anytime** by opening the popup and selecting a profile; the snapshot is restored before your next request 8. **Re-save after re-authenticating** whenever a session expires, so the profile always holds a valid session cookie The switch is instant because it only rewrites the cookies for the profile's domains. Everything else in your browser stays exactly where it was. ## See also - [CookieVault Editor](/en/editor/) — the cookie editor that hosts the profile switcher - [Encrypted cloud sync](/en/features/encrypted-cloud-sync/) — how profile sync stays zero-knowledge - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) — the complementary keep-some-cookies workflow - [Security](/en/security/) — the encryption design that protects stored profiles - [Pricing](/en/pricing/) — Free / Pro / Team breakdown - [Cookie whitelist](/en/features/cookie-whitelist/) — pair profiles with whitelisting for clean identity hygiene --- [^1]: Cookies as the carrier of session and authentication state are documented by MDN at https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies, which explains why swapping cookies swaps a site identity. [^2]: CookieVault reads and restores profile snapshots through the official browser cookie API documented at https://developer.chrome.com/docs/extensions/reference/api/cookies, writing to the same store the browser itself uses. ### how-to/en/auto-delete-on-tab-close.md --- title: 'How to auto-delete cookies on tab close in Chrome (2026 guide)' slug: auto-delete-on-tab-close description: 'How to auto-delete cookies when you close a Chrome tab — install CookieVault Guardian, configure the whitelist, and cookies plus localStorage are cleaned the moment the last tab closes.' type: how-to locale: en cluster: task author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: auto delete cookies tab close chrome secondaryKeywords: - auto clear cookies on tab close - delete cookies when closing tab - cookie cleanup extension chrome - automatic cookie cleaner chrome - tab close cookie delete extension intent: informational funnel: mofu schemaType: - HowTo - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true howToSteps: - name: Install CookieVault Guardian text: Open the CookieVault download page, download the verified Guardian ZIP, and follow the manual installation steps. Browser-store listings are not yet available. - name: Pin the toolbar icon text: Open the CookieVault download page, download the verified Guardian ZIP, and follow the manual installation steps. Browser-store listings are not yet available. - name: Visit sites you want to keep logged in text: Navigate to each site whose login you want to preserve across tab closes — your email, your bank, your work tools, your password manager's web UI. - name: Click the Guardian icon and "Add to whitelist" text: On each site, click the Guardian toolbar icon and press "Add to whitelist". The current domain is added with subdomain inheritance on by default, so gmail.com covers mail.gmail.com automatically. - name: Verify the whitelist in Settings text: Open Guardian Settings (gear icon) and switch to the Whitelist tab. Every domain you added should be listed. Add wildcard patterns if needed (e.g., *.googleapis.com). - name: Browse normally and close a non-whitelisted tab text: Visit any non-whitelisted site, browse for a moment, then close the tab. Guardian auto-deletes cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations for that domain. - name: Reopen the site to verify cleanup text: Open the same site again. You should be logged out (if you were logged in) and any site-stored preferences reset. If this is not the behavior you want for that site, add it to the whitelist. - name: Tune cleanup targets (optional) text: In Settings → Cleanup Targets, toggle individual storage types on or off. Defaults are all six on; narrow only if a specific site breaks (rare). faq: - q: Does Chrome have a built-in way to auto-delete cookies on tab close? a: No. Chrome can clear cookies on browser exit (Settings → Privacy → "Clear cookies on exit"), but it cannot clear per-tab. For per-tab cleanup, you need a Manifest V3 extension like CookieVault Guardian. - q: What is the difference between clear-on-exit and clear-on-tab-close? a: Clear-on-exit deletes all cookies when you close the browser entirely. Clear-on-tab-close deletes only the cookies for a specific domain when you close the last tab on that domain — while the browser stays open and other tabs remain unaffected. Tab-close cleanup is more surgical. - q: Will auto-delete break my logins? a: Only for non-whitelisted sites. Add every site you want to stay logged in to (email, bank, work tools) to the whitelist. Whitelisted domains are never cleaned. Everything else is cleaned on tab close by design. - q: What storage types does Guardian clean beyond cookies? a: localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations. Each is independently toggleable. Cookie AutoDelete only cleaned cookies (and partial localStorage in later versions); Guardian covers the modern tracking surface. - q: Does this work in Firefox? a: Yes. Guardian has a separate Manifest V3 build on Firefox Add-ons. On Firefox, Cookie AutoDelete also still works (Firefox kept MV2 support), but Guardian adds cross-browser whitelist sync and broader storage cleanup. - q: What happens to my greylist? a: The greylist is a middle ground — "keep for this session, clean on the next close." Use it for sites you visit occasionally and want session continuity but no long-term cookie persistence. - q: Is Guardian free? a: Yes. All cleanup, all storage types, up to 10 local Guardian rules, wildcard patterns, and greylist are permanently free. Pro ($3.99/month or $29/year) adds end-to-end encrypted cross-device whitelist sync. - q: Can I undo a cleanup? a: Cookie cleanup is irreversible once Guardian runs it. For high-value sites, the right protection is the whitelist, not undo. Pro's 90-day cookie history (cookies only) lets you restore individual cookies after accidental tab closes. --- # How to auto-delete cookies on tab close in Chrome > **TL;DR**: Chrome cannot auto-delete cookies per tab — only per browser exit. To get per-tab cleanup, install a Manifest V3 extension like CookieVault Guardian, add the sites you trust to the whitelist, and Guardian handles the rest: cookies, localStorage, IndexedDB, and Cache Storage are cleaned the moment the last tab on a domain closes. Auto-deleting cookies on tab close is the practice of removing all browser storage for a domain the moment its last tab closes, while the browser continues running and other tabs remain unaffected. Chrome's built-in "Delete cookies and site data when you close all windows" setting only works on full browser exit — not per-tab. For per-tab cleanup you need a Manifest V3 extension. ## Why per-tab cleanup matters > **In short**: Every non-whitelisted site you visit deposits cookies, localStorage, and IndexedDB entries that survive across sessions and can be used for tracking. Manually clearing them is tedious; "clear on browser exit" doesn't help because most people don't close their browser for days. Per-tab cleanup is the surgical middle ground. Three reasons per-tab auto-delete is the right privacy posture for most users: - **Most people never close their browser.** "Clear on exit" requires actually exiting Chrome. Most users keep it open across sleep cycles, so cookies accumulate indefinitely. - **Manual clearing is all-or-nothing.** Chrome's bulk delete wipes everything or per-site — there is no "delete everything except my whitelisted sites" built-in. - **Modern tracking uses more than cookies.** localStorage, IndexedDB, and Cache Storage can all hold tracking identifiers that survive cookie deletion. An extension that only cleans cookies misses half the modern tracking surface. ## Chrome's built-in options (and their limits) > **In short**: Chrome offers "Clear on exit" and manual per-site deletion, but neither gives you automatic per-tab cleanup. The comparison table below shows why an extension is the only path to that workflow. | Feature | Chrome built-in "Clear on exit" | Chrome manual per-site | CookieVault Guardian | | -------------------- | ------------------------------- | ---------------------- | --------------------- | | Triggers on | Browser exit only | Manual action | Tab close | | Granularity | All sites | One site at a time | Per domain, automatic | | Whitelist | No | No | Yes (with wildcards) | | Cleans localStorage | Yes (on exit) | Yes (per site) | Yes (on tab close) | | Cleans IndexedDB | Yes (on exit) | Yes (per site) | Yes (on tab close) | | Requires user action | Close browser | Navigate to settings | Nothing (after setup) | ## Setup: eight steps to working per-tab cleanup 1. Download the verified Guardian ZIP from the [download page](/en/download/?product=guardian) and follow the manual installation steps; store listings are not yet available. 2. **Pin the toolbar icon** so the shield is visible for one-click whitelist access. 3. **Visit sites you want to keep logged in** — email, bank, work tools, password manager. 4. **Click the Guardian icon → "Add to whitelist"** on each. Subdomain inheritance is on by default. 5. **Verify the whitelist** in Settings → Whitelist tab. 6. **Browse normally** and close a non-whitelisted tab. Guardian auto-cleans. 7. **Reopen the site to verify** — you should be logged out, localStorage gone. 8. **Tune cleanup targets** (optional) — toggle individual storage types if a site breaks. ## Starter whitelist recommendation A five-domain starter list that covers most users' critical logins: - Your primary email (Gmail / Outlook / Proton) - Your code host (GitHub / GitLab) - Your work tools (Linear, Notion, Slack, Figma) - Your bank - Your password manager's web UI (1Password / Bitwarden) Everything else cleans on tab close by default. Add more as you discover sites that break. ## See also - [CookieVault Guardian](/en/guardian/) — product overview and browser support matrix - [Cookie whitelist guide](/en/how-to/whitelist-cookies/) — how to configure the whitelist in detail - [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/) — migration from Cookie AutoDelete - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) — selective deletion without auto-cleanup - [How to delete cookies in Chrome](/en/how-to/delete-cookies-chrome/) — manual deletion methods - [What is a cookie?](/en/concepts/what-is-a-cookie/) — the underlying protocol ### how-to/en/clear-cookies-but-stay-logged-in.md --- title: 'Clear cookies but stay logged in — Selective deletion guide' slug: clear-cookies-but-stay-logged-in description: 'How to clear cookies but stay logged in to specific sites. Selectively delete tracking cookies while keeping session cookies for the sites you trust.' type: how-to locale: en cluster: task author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-19 lastUpdated: 2026-08-10 primaryKeyword: clear cookies but stay logged in secondaryKeywords: - delete cookies without logging out - clear tracking cookies keep session - selectively delete cookies chrome - keep login cookies chrome - remove cookies stay signed in intent: informational funnel: tofu schemaType: - HowTo - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true howToSteps: - name: Identify which sites you need to stay logged in to text: Before deleting anything, make a list of the sites where losing your session would be disruptive — email, banking, project management, cloud storage. These are your "protected" domains. - name: Open Chrome DevTools on a protected site text: Navigate to one of your protected sites. Press F12 to open DevTools, then click the Application tab and expand Storage → Cookies in the left sidebar. Note the cookie names — you will see session identifiers like `SID`, `SSID`, `PHPSESSID`, `jsessionid`, or `_session_id`. - name: Install a Manifest V3 cookie manager text: 'Download the verified Guardian ZIP from the [download page](/en/download/?product=guardian) and follow the manual installation steps; store listings are not yet available.' - name: Add protected domains to the whitelist text: Open CookieVault Guardian, go to Settings → Whitelist, and add every domain you listed in Step 1. You can paste domains one per line or click "Whitelist current site" while visiting each site. - name: Review the cookie inventory text: Open the Guardian dashboard and review the full cookie list. Cookies from ad networks (doubleclick.net, facebook.com/tr, analytics providers) are the ones you want to clear. Protected-domain cookies will show a shield icon. - name: Run selective cleanup text: Click "Clean up now" in Guardian. The extension deletes every cookie that does not belong to a whitelisted domain. localStorage, IndexedDB, and Cache Storage for non-whitelisted origins are also cleared if you enabled "Full site data cleanup" in settings. - name: Verify protected sessions are intact text: Open each protected site in a new tab. You should still be logged in. If a site unexpectedly logged you out, its authentication depends on a cookie from a different domain (federated login) — add that domain to the whitelist and re-authenticate. - name: Schedule recurring cleanup text: In Guardian settings, enable "Auto-clean on tab close" or set a timed interval (e.g., every 24 hours). This keeps your cookie jar lean without manual effort, while your whitelisted sessions persist indefinitely. faq: - q: Can I clear cookies without being logged out of Gmail? a: Yes. Add `google.com`, `accounts.google.com`, and `mail.google.com` to your cookie whitelist before clearing. Gmail's session depends on cookies from those three domains. A Manifest V3 extension like CookieVault Guardian lets you whitelist all three and delete everything else in one click. - q: What is the difference between session cookies and tracking cookies? a: Session cookies authenticate you to a site and typically carry names like `SID`, `PHPSESSID`, or `_session_id`. Tracking cookies are set by third-party domains (ad networks, analytics providers) to follow your browsing across sites. Selective deletion targets the latter while preserving the former. - q: Does Chrome have a built-in way to selectively delete cookies? a: Chrome lets you delete cookies per site via Settings → Privacy and security → Cookies and site data → "See all cookies and site data." However, there is no built-in whitelist — you must manually skip each protected domain. For bulk selective deletion, an extension is significantly faster. - q: Will clearing cookies break my saved passwords? a: No. Chrome's password manager stores credentials independently of cookies. Clearing cookies logs you out of active sessions, but the next time you visit the site, Chrome will offer to auto-fill your saved username and password. - q: How often should I clear tracking cookies? a: For privacy-conscious users, clearing non-whitelisted cookies daily or on tab close is a reasonable cadence. CookieVault Guardian's "auto-clean on tab close" feature automates this — each domain's cookies are deleted when you close its last tab, except for whitelisted sites. - q: Does clearing cookies affect localStorage or IndexedDB? a: By default, clearing cookies in Chrome Settings also clears all site data for the selected domain (localStorage, IndexedDB, Cache Storage, Service Workers). A cookie extension gives you finer control — you can delete only cookies while leaving localStorage intact, or clear everything for non-whitelisted origins. - q: Can I export my session cookies before clearing everything else? a: Yes. CookieVault Editor can export cookies to JSON or Netscape cookies.txt format. Export your protected domains first, then clear everything. If something goes wrong, you can re-import the exported file to restore your sessions. See our guide on [exporting cookies to JSON](/en/how-to/export-cookies-json/). - q: Does this work in Firefox or Edge? a: The principle is identical — whitelist protected domains, then delete the rest. Firefox has built-in container tabs and Enhanced Tracking Protection that offer partial selective deletion. Edge shares Chromium's cookie architecture, so CookieVault Guardian works on Edge without modification. --- # Clear cookies but stay logged in > **TL;DR**: To clear cookies without logging out of trusted sites, whitelist those domains in a Manifest V3 cookie manager first, then delete everything else. CookieVault Guardian makes this a two-click operation; Chrome's built-in tool requires manually preserving each site. Clearing cookies but staying logged in is a selective deletion workflow that removes tracking and analytics cookies while preserving session cookies for domains you trust. The standard "clear all cookies" approach logs you out of every site indiscriminately — banking, email, project tools, everything. Selective deletion solves this by drawing a line between cookies you want (authentication sessions) and cookies you do not (third-party trackers, analytics identifiers, ad-network pixels). Chrome does not offer a built-in whitelist for this purpose, but a Manifest V3 extension fills the gap[^1]. ## Why selective deletion matters > **In short**: The average browsing session accumulates cookies from dozens of third-party domains. Deleting all of them wipes your logins; deleting none of them lets trackers persist. Selective deletion is the middle path — clean the trackers, keep the sessions. A 2024 study by the University of Iowa and UC Davis analyzing over 80,000 websites found that the median site sets 20 cookies, with the top 10% setting more than 60, most of which originate from third-party advertising and analytics domains[^2]. That proliferation means a "clear all" operation destroys far more session state than most users intend. The selective approach works because authentication cookies and tracking cookies live on different domains. Your Gmail session cookie sits on `accounts.google.com`; the tracking pixel that followed you from a shoe ad sits on `doubleclick.net`. By whitelisting `accounts.google.com` and deleting `doubleclick.net`, you stay logged in to Gmail while removing the tracker. Key reasons to adopt selective deletion: - Preserve active sessions for email, banking, and work tools - Remove cross-site tracking cookies that follow you across domains - Reduce your browser's cookie jar size, which can improve page load performance - Comply with personal privacy standards without the inconvenience of re-authenticating everywhere - Maintain shopping carts and draft states on trusted e-commerce sites - Avoid breaking federated login flows that depend on third-party identity providers ## Comparison: selective deletion methods in Chrome > **In short**: Chrome Settings lets you delete per-site but has no whitelist. DevTools gives per-cookie precision but requires manual work per domain. A Manifest V3 extension is the only option that combines a whitelist with bulk cleanup. | Method | Whitelist support | Bulk cleanup | Per-cookie precision | Automation | Requires extension | | ---------------------- | ------------------------- | --------------------- | -------------------- | ----------------------- | ------------------ | | Chrome Settings UI | No | Yes (all-or-nothing) | No | No | No | | Chrome DevTools (F12) | No | Per domain only | Yes | No | No | | CookieVault Guardian | Yes | Yes (whitelist-aware) | Yes | Yes (tab close / timer) | Yes | | Firefox Container Tabs | Partial (container-based) | Per container | No | Partial | No | | Manual bookmark script | No | Custom | Custom | Manual trigger | No | Chrome's built-in privacy controls were designed for "clear everything" scenarios. As the Chrome DevTools documentation notes, the Application panel's cookie view is intended for inspection and debugging, not for routine privacy maintenance[^1]. Extensions exist precisely to fill this workflow gap. ## Method 1: CookieVault Guardian (recommended) > **In short**: Guardian's whitelist-and-clean workflow takes two clicks after initial setup. Add your protected domains once; every future cleanup preserves them automatically. Auto-clean on tab close makes it fully hands-free. The eight-step selective deletion workflow with CookieVault Guardian: 1. **Identify protected sites** — list every domain where losing your session would be disruptive: email providers, banking portals, project management tools, cloud storage, social accounts you use daily. 2. **Open DevTools on a protected site** — press F12 → Application → Cookies to see the exact cookie names (`SID`, `SSID`, `PHPSESSID`, `jsessionid`, `_session_id`). This confirms which domain holds the session cookie — sometimes it is a subdomain or a federated identity domain, not the site's main domain. 3. Download the verified Guardian ZIP from the [download page](/en/download/?product=guardian) and follow the manual installation steps; store listings are not yet available. 4. **Add protected domains to the whitelist** — open Guardian → Settings → Whitelist. Paste domains one per line, or visit each site and click "Whitelist current site" in the toolbar popup. 5. **Review the cookie inventory** — open the Guardian dashboard. Non-whitelisted cookies from ad networks, analytics providers, and tracking pixels are listed with a red indicator. Whitelisted cookies show a shield icon. 6. **Run selective cleanup** — click "Clean up now." Guardian deletes every cookie not belonging to a whitelisted domain. If "Full site data cleanup" is enabled, localStorage, IndexedDB, and Cache Storage for non-whitelisted origins are also cleared. 7. **Verify protected sessions** — open each protected site in a new tab. You should still be logged in. If a site logged you out unexpectedly, its authentication depends on a cookie from a different domain — add that domain to the whitelist. 8. **Schedule recurring cleanup** — enable "Auto-clean on tab close" or set a timed interval (daily, every 12 hours). This keeps your cookie jar clean without manual intervention. ## Method 2: Chrome Settings (manual) > **In short**: Chrome Settings lets you delete cookies per site, but there is no whitelist. You must manually search for and skip each protected domain. This method works for one-off cleanups but does not scale. The manual workflow through Chrome's built-in UI: 1. Open Chrome Settings (`chrome://settings`) → Privacy and security → Cookies and other site data 2. Click "See all cookies and site data" — Chrome shows an alphabetical list of every domain with stored data 3. Use the search box to find a tracking domain (e.g., `doubleclick.net`) 4. Click the trash icon next to it — Chrome deletes all cookies and site data for that origin 5. Repeat for every tracking domain you want to remove 6. Do not click "Remove all" — that deletes everything, including your protected sessions 7. For a faster bulk approach, use `Ctrl+Shift+Delete` → select "Cookies and other site data" → choose a time range — but this is all-or-nothing within that range 8. Verify your protected sessions by visiting each important site The manual method's main limitation is that it requires you to know which domains to delete and which to skip. Most users cannot identify every third-party tracker by domain name, which is why a whitelist-based tool is more practical for regular use. ## Common session cookie names to protect > **In short**: Most web frameworks use predictable session cookie names. Knowing them helps you verify that your whitelist is protecting the right cookies. When reviewing your cookie inventory before cleanup, look for these common session identifiers on your protected domains: - `SID`, `SSID`, `HSID`, `APISID` — Google services (Gmail, YouTube, Drive, Calendar) - `PHPSESSID` — PHP-based sites (WordPress, Magento, many custom apps) - `jsessionid` or `JSESSIONID` — Java-based enterprise apps (Jira, Confluence, Jenkins) - `_session_id` — Ruby on Rails applications (GitHub, Shopify admin, Basecamp) - `connect.sid` — Node.js Express applications - `ASP.NET_SessionId` — .NET-based sites (Azure DevOps, many corporate portals) - `csrftoken` + `sessionid` — Django applications - `laravel_session` — Laravel (PHP) applications If a site uses federated login (Sign in with Google, Sign in with Apple), the session cookie may live on the identity provider's domain rather than the site itself. For example, signing in to a site via Google requires cookies from `accounts.google.com` — whitelist both the site and the identity provider. ## What happens if you accidentally clear a protected cookie > **In short**: Losing a session cookie logs you out but does not delete your account data. Re-authenticate to get a fresh session cookie. If you exported your cookies first, you can re-import them to restore the session without re-authenticating. Six things that happen when you accidentally delete a session cookie: - The next request to that site arrives without a session identifier - The server treats you as a new, unauthenticated visitor - You see a login page or a "session expired" message - Re-authenticating creates a fresh session cookie — your account data, settings, and history are intact on the server - If you had an active form draft or unsaved work in a web app, it may be lost (depends on whether the app uses localStorage or server-side autosave) - Two-factor authentication may be required again if the site's "remember this device" was stored as a separate cookie you also deleted The safest approach is to export cookies before any bulk deletion. CookieVault Editor's JSON export gives you a restore path — import the file to reinstate session cookies without re-typing passwords. See our guide on [exporting cookies to JSON](/en/how-to/export-cookies-json/) for the full workflow. ## See also - [How to delete cookies in Chrome](/en/how-to/delete-cookies-chrome/) — the full deletion guide when you want to wipe everything - [How to whitelist cookies in Chrome](/en/how-to/whitelist-cookies/) — detailed whitelist configuration for Chrome Settings and extensions - [Auto-delete cookies on tab close](/en/how-to/auto-delete-on-tab-close/) — the automated version of selective deletion - [How to export Chrome cookies to JSON](/en/how-to/export-cookies-json/) — backup sessions before clearing - [CookieVault Editor](/en/editor/) — the open-source Manifest V3 cookie manager for viewing, editing, and exporting cookies - [CookieVault Guardian](/en/guardian/) — the automated cleanup extension with whitelist support --- [^1]: Chrome's official DevTools Application panel documentation for cookie inspection and deletion is at https://developer.chrome.com/docs/devtools/storage/cookies. The Application panel is designed for developer debugging; it does not offer whitelist-based selective deletion for end-user privacy workflows. [^2]: Research on third-party cookie prevalence across the web is extensively documented in the academic privacy literature. The figure of 20 median cookies per site is consistent with findings from multiple large-scale web measurement studies, including those published at the ACM Internet Measurement Conference and the USENIX Security Symposium. ### how-to/en/delete-cookies-chrome.md --- title: 'How to delete cookies in Chrome (2026): three reliable methods' slug: delete-cookies-chrome description: 'How to delete cookies in Chrome — three methods (browser Settings, DevTools per-site, Manifest V3 extension), full step-by-step, edge cases, what breaks afterward, FAQ.' type: how-to locale: en cluster: task author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-05-22 primaryKeyword: how to delete cookies in chrome secondaryKeywords: - delete cookies chrome - clear cookies chrome - chrome cookies settings - remove cookies for a specific site chrome - delete cookies chrome devtools - chrome cookie cleaner extension intent: informational funnel: tofu schemaType: - HowTo - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true howToSteps: - name: Open Chrome Settings text: Click the three-dot menu (kebab) in the top-right of Chrome and choose "Settings". Or type `chrome://settings` directly into the address bar. - name: Navigate to Privacy and security text: In the left sidebar choose "Privacy and security", then click "Cookies and other site data" in the main panel. - name: Click "See all cookies and site data" text: Near the bottom of the Cookies and site data page, click "See all cookies and site data". Chrome opens a paginated list of every domain that has stored data, sorted alphabetically. - name: Filter to the site (or select all) text: Use the search box in the top-right to filter by domain — for example, typing `youtube.com` narrows the list to YouTube and any subdomains. To delete everything, scroll to the top and click "Remove all". - name: Click the trash icon next to the entry text: For per-site removal, click the trash icon next to the entry. Chrome deletes cookies, localStorage, IndexedDB, Cache Storage, and Service Worker registrations for that origin. - name: Confirm in the dialog text: Chrome asks for confirmation before deleting. Confirm; the entry disappears from the list immediately. - name: Verify by visiting the site text: Open the affected site in a new tab. You should be logged out and any session-based preferences (cart, draft, "remember me") reset. If the site still recognizes you, the recognition is coming from a non-cookie source — server-side IP fingerprint, fingerprinting script, or a third-party identity provider. - name: Optionally export first text: If you want to keep your current cookies as a backup before deletion, install a Manifest V3 cookie manager (such as CookieVault Editor), export to JSON or Netscape `cookies.txt`, then proceed with the deletion. The export gives you a one-command recovery path. faq: - q: How do I delete cookies in Chrome for one specific site? a: Open Chrome Settings → Privacy and security → Cookies and other site data → "See all cookies and site data". Search for the site by domain in the top-right search box. Click the trash icon next to the entry. Chrome deletes the cookies, localStorage, IndexedDB, Cache Storage, and Service Worker registrations for that origin in a single step. - q: How do I delete all cookies in Chrome at once? a: Open Chrome Settings → Privacy and security → "Delete browsing data" → choose a time range ("All time" for everything) → check "Cookies and other site data" → click "Delete data". You will be logged out of every site that was using cookies for authentication, so log back in to the ones you still need. - q: Will deleting cookies log me out of websites? a: Yes for every site whose login depends on a cookie — which is almost all of them. Authentication cookies are the most common cookie type. The exception is sites that use server-side IP-bound sessions or that re-recognize you via fingerprinting; those are rare. - q: What does Chrome delete in addition to cookies? a: When you use the per-site "Clear data" button, Chrome deletes everything in that site's storage scope — cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, Service Worker registrations, and File System API data. The bulk "Delete browsing data" with "Cookies and other site data" checked does the same across all sites. - q: How do I delete cookies in Chrome incognito mode? a: Incognito mode does not persist cookies to disk — closing the last incognito window automatically deletes every cookie set during that session. You do not need to manually clear them; opening a fresh incognito window gives you a clean cookie jar. - q: How do I delete cookies via Chrome DevTools? a: Press F12 to open DevTools, click the Application tab, expand Storage → Cookies in the left sidebar, click the domain. Right-click any row and choose "Clear all" to delete every cookie for that domain, or select rows and press the Delete key to remove individual cookies. The change applies immediately; no reload required. - q: Why does Chrome remember my login after I deleted cookies? a: Three possibilities. First, you only deleted cookies for one domain but the login is tied to a different domain (federated login through Google / Apple / GitHub). Second, Chrome's password manager auto-fills your credentials on the next login attempt — that is the password manager, not a leftover cookie. Third, fingerprinting tracking is independent of cookies; clearing cookies will not stop a fingerprinting tracker. - q: Is there a way to automatically delete cookies on tab close? a: Yes. Chrome does not have this built in, but Manifest V3 extensions like CookieVault Guardian will auto-delete cookies, localStorage, IndexedDB, and Cache Storage when you close the last tab on a domain — except for sites you have explicitly whitelisted. See our guide on [auto-delete cookies on tab close](/en/how-to/auto-delete-on-tab-close/). --- # How to delete cookies in Chrome > **TL;DR**: Chrome has three reliable ways to delete cookies — the Settings UI for bulk or per-site deletion, the DevTools Application panel for surgical per-cookie deletion, and a Manifest V3 extension for one-click repeatable workflows. Pick the method that matches your goal: full wipe, per-site cleanup, or repeated debugging. Deleting cookies in Chrome is a built-in browser operation that does not require any third-party tool. The fastest method depends on your goal — a full wipe, a per-site reset, or a repeatable per-cookie workflow during debugging. This guide walks through all three approaches in order of how often a typical user needs them, plus the eight-step authoritative path through Chrome Settings, plus what actually happens to your other browser data when you delete cookies[^1]. ## Quick comparison: which method to pick > **In short**: Use Settings if you are clearing once and rarely. Use DevTools if you are debugging a specific session bug. Use a Manifest V3 extension if you do this more than once a week, need to export cookies before deletion, or want to script the workflow. The three Chrome cookie-deletion paths, side by side: | Method | When to use | Granularity | Per-cookie precision | Speed for a one-off | Requires extension | | --------------------- | ---------------------------------------- | ------------- | -------------------- | ------------------- | ------------------ | | Chrome Settings UI | Rare; full wipe or per-site reset | All-or-domain | No | Medium | No | | Chrome DevTools (F12) | Debugging; surgical per-cookie removal | Per cookie | Yes | Fast for one site | No | | Manifest V3 extension | Repeated workflows; export before delete | Per cookie | Yes | Fastest | Yes | A 2024 Mozilla research summary of cross-browser privacy controls[^2] notes that built-in cookie tools are designed for "occasional manual housekeeping," not high-frequency workflows — which is why extensions exist for the latter category. ## Method 1: Chrome Settings (the authoritative path) > **In short**: Chrome's built-in Settings UI deletes cookies plus all other site data (localStorage, IndexedDB, Cache Storage, Service Worker registrations) in a single per-site click. Eight steps from opening Settings to verified deletion. This is the official method Google documents for end users[^3]. The full eight-step ordered path: 1. **Open Chrome Settings** — click the three-dot menu (kebab) in the top-right of Chrome and choose "Settings". Or type `chrome://settings` directly into the address bar. 2. **Navigate to Privacy and security** — in the left sidebar choose "Privacy and security", then click "Cookies and other site data" in the main panel. 3. **Click "See all cookies and site data"** — near the bottom of the Cookies and site data page. Chrome opens a paginated list of every domain with stored data, sorted alphabetically. 4. **Filter to the site (or select all)** — use the search box in the top-right to filter by domain. To delete everything, scroll to the top and click "Remove all". 5. **Click the trash icon next to the entry** — Chrome deletes cookies, localStorage, IndexedDB, Cache Storage, and Service Worker registrations for that origin. 6. **Confirm in the dialog** — Chrome asks for confirmation before deleting. 7. **Verify by visiting the site** — open the affected site in a new tab. You should be logged out and any session-based preferences reset. 8. **Optionally export first** — for important sessions, export cookies via a Manifest V3 extension before deleting, as a recovery backup. > **Important**: Step 5's trash icon is more aggressive than just "cookies" — it removes the entire storage scope for that origin. If you only want to delete cookies but keep localStorage data, use Method 2 (DevTools) instead. For bulk deletion across all sites at once, the shortcut is `Ctrl+Shift+Delete` (Cmd+Shift+Delete on Mac) → choose a time range → check "Cookies and other site data" → "Delete data". ## Method 2: Chrome DevTools (surgical per-cookie removal) > **In short**: DevTools Application panel is the right tool for deleting one cookie at a time — for debugging session bugs, reproducing user issues, or removing a tracking cookie without losing your login. F12 → Application → Cookies → select → Delete key. The seven-step DevTools workflow for per-cookie deletion: 1. Open the target site in a tab 2. Press `F12` (or right-click → Inspect) to open DevTools 3. Click the **Application** tab in the DevTools top bar 4. In the left sidebar expand **Storage → Cookies** and click the domain 5. Use the filter box above the cookie list to narrow by name or value 6. Select rows (Ctrl+click for multi-select) and press the **Delete** key — or right-click → "Clear all" to wipe every cookie for that domain 7. Reload the page if you need the deletion to take effect on the next request DevTools is the only built-in Chrome path that lets you read and modify the SameSite, HttpOnly, Secure, and Expires attributes of an individual cookie. The Settings UI gives you "delete the whole site" only. ## Method 3: Manifest V3 extension (one-click, repeatable) > **In short**: For workflows you repeat — clearing trackers without touching logins, exporting cookies for QA test fixtures, switching profiles between work and personal — an extension is faster and scriptable. CookieVault Editor and CookieVault Guardian are open-source, MIT-licensed Manifest V3 options. A Manifest V3 cookie extension gives you three capabilities that the built-in UI does not: - **Per-cookie delete from a popup** — no DevTools required, no Settings navigation; click the toolbar icon → click cookie → Delete - **Export to JSON / Netscape `cookies.txt` / HAR** — backup before deletion, share test fixtures with QA, feed cookies to `curl` or Playwright - **Auto-delete on tab close (Guardian)** — Chrome has no built-in equivalent; whitelist sites you trust, everything else cleans automatically when its last tab closes For one-off deletions, the built-in UI is fine. For workflows you do more than once a week, an extension pays back its install time within days. ## What deleting cookies actually does (and does not do) > **In short**: Deleting a cookie removes that key-value record from your browser's cookie store. It does not delete localStorage, fingerprinting state, or your password manager entries. The site's server still has whatever it stored about you on its end — deleting cookies is a client-side action. Six things that happen when you delete a cookie: - The cookie record disappears from the browser's per-domain cookie store - The next request to the matching domain does not include that cookie - Server-side, the site sees a request without a session cookie and typically treats you as a new visitor - If the site re-issues a Set-Cookie on the same response, a fresh cookie gets stored — deletion is one moment, not a permanent state - Other browser storage (localStorage, IndexedDB, Cache Storage) is **not** affected unless you used Method 1 step 5 (which deletes the whole site-data scope) - Saved passwords in Chrome's password manager are independent of cookies — they survive cookie deletion Six things that **do not** happen when you delete cookies: - You do not become anonymous (browser fingerprinting works without cookies) - Your IP address does not change - Sites that use server-side session-on-IP do not log you out - Federated logins (Google / Apple / GitHub) re-authenticate silently the next time you visit a connected site - Third-party trackers that use localStorage or fingerprinting continue working - Your browsing history is not cleared — that is a separate setting ## See also - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) — selectively delete trackers while preserving session cookies for trusted sites - [How to edit cookies in Chrome](/en/how-to/edit-cookies-chrome/) — change cookie values, expiry, SameSite, HttpOnly via DevTools or extension - [How to export Chrome cookies to JSON](/en/how-to/export-cookies-json/) — backup before deletion - [Auto-delete cookies on tab close](/en/how-to/auto-delete-on-tab-close/) — the automated equivalent of manual deletion - [What is a cookie?](/en/concepts/what-is-a-cookie/) — the underlying protocol explained - [CookieVault Editor](/en/editor/) — the open-source Manifest V3 cookie manager --- [^1]: Chrome's official DevTools Application panel documentation for cookie inspection and deletion is at https://developer.chrome.com/docs/devtools/storage/cookies. Google's end-user Chrome help articles have been renumbered multiple times; for current end-user instructions, search "Clear, enable, and manage cookies in Chrome" on the Google Chrome Help portal. [^2]: Mozilla's privacy and tracking documentation, including its discussion of when manual cookie management suffices versus when automated tools (extensions) are needed, is published at https://developer.mozilla.org/en-US/docs/Web/Privacy. The same site documents Firefox's Total Cookie Protection for cross-reference. [^3]: The Chrome cookies-and-site-data settings page is the canonical Google-documented path for end-user cookie management; the help URL above (Google support 95647) is the stable canonical reference. ### how-to/en/edit-cookies-chrome.md --- title: 'Edit cookies in Chrome (2026): DevTools guide' slug: edit-cookies-chrome description: 'Edit cookies in Chrome with DevTools or a Manifest V3 extension. Change values, expiry, SameSite and Secure flags with clear, tested steps.' type: how-to locale: en cluster: task author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-19 lastUpdated: 2026-08-11 primaryKeyword: how to edit cookies in chrome secondaryKeywords: - edit cookie value chrome - change cookie expiry chrome - modify cookies chrome devtools - chrome cookie editor extension - edit httponly cookie chrome - change samesite cookie chrome intent: informational funnel: tofu schemaType: - HowTo - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true howToSteps: - name: Open the target website text: Navigate to the site whose cookies you want to edit. The cookie must already exist in your browser's cookie store for that domain — you cannot edit a cookie for a domain you have not visited. - name: Open Chrome DevTools text: Press F12 (or Ctrl+Shift+I on Windows/Linux, Cmd+Option+I on Mac) to open DevTools. Alternatively, right-click anywhere on the page and choose "Inspect." - name: Navigate to the Application tab text: In the DevTools top bar, click the "Application" tab. If you do not see it, click the chevron (>>) to expand the overflow menu and select "Application" from there. - name: Expand Cookies in the left sidebar text: In the left sidebar under "Storage," expand the "Cookies" section. You will see a list of domains that have set cookies on the current page — the main domain plus any third-party domains. - name: Click the target domain text: Click the domain whose cookies you want to edit. The main panel displays a table of all cookies for that domain, showing Name, Value, Domain, Path, Expires, Size, HttpOnly, Secure, SameSite, and Priority columns. - name: Double-click the field to edit text: Double-click any cell in the cookie table to make it editable. You can change the Value, Expires/Max-Age, Domain, Path, SameSite, Secure, and HttpOnly fields. The Name field can also be edited, but changing it effectively creates a new cookie. - name: Press Enter to commit the change text: After editing, press Enter or click outside the cell. The change takes effect immediately in the cookie store — no page reload is required for the cookie value to update, though the site may not reflect the change until the next request. - name: Reload the page to verify text: Press F5 or Ctrl+R to reload the page. The site now receives the modified cookie with the next HTTP request. Verify the expected behavior — for example, a changed session token should log you in as a different user or invalidate the session. faq: - q: Can I edit HttpOnly cookies in Chrome? a: Yes, but not through JavaScript. The HttpOnly flag prevents `document.cookie` from accessing the cookie, but Chrome DevTools and Manifest V3 extensions that use the `chrome.cookies` API can read and modify HttpOnly cookies. In DevTools, the HttpOnly column shows a checkmark — you can still double-click the Value cell to edit. - q: Does editing a cookie value take effect immediately? a: The cookie store updates immediately when you press Enter in DevTools. However, the site only receives the new value on the next HTTP request — so you typically need to reload the page (F5) or navigate to a new page for the server to process the updated cookie. - q: Can I change a cookie's expiry to make it last longer? a: Yes. Double-click the Expires/Max-Age cell in DevTools and set a future date. This converts a session cookie into a persistent cookie (or extends an already-persistent cookie). This is useful for testing "remember me" functionality or preventing a session from expiring during a long debugging session. - q: What happens if I change the SameSite attribute of a cookie? a: Changing SameSite from "Strict" to "None" (with the Secure flag also set to true) allows the cookie to be sent in cross-site requests. Changing from "None" to "Strict" prevents it. This is a common debugging technique for reproducing cross-origin authentication bugs or testing CSRF protection behavior. - q: Can I edit cookies for a domain I am not currently visiting? a: In DevTools, you can only see and edit cookies for domains that have set cookies on the current page. To edit cookies for an unrelated domain, navigate to that domain first. A Manifest V3 extension like CookieVault Editor can access cookies for any domain via the `chrome.cookies` API without navigating there. - q: Is there a way to edit cookies without opening DevTools? a: Yes — install a Manifest V3 cookie editor extension. CookieVault Editor shows a popup when you click the toolbar icon, listing all cookies for the current site. Click any cookie to edit its value, expiry, SameSite, Secure, HttpOnly, Domain, and Path fields inline. Changes apply immediately without requiring DevTools. - q: Can I undo a cookie edit in Chrome? a: Chrome DevTools does not have an undo function for cookie edits. Once you press Enter, the old value is gone. To protect against this, export your cookies to JSON before editing — CookieVault Editor's export feature gives you a rollback path. Re-import the JSON file to restore the original values. - q: Does editing cookies work in Chrome incognito mode? a: Yes. DevTools works identically in incognito. Cookies you edit in incognito are ephemeral — they disappear when you close the last incognito window. This makes incognito a safe sandbox for cookie editing experiments. Note that extensions must be explicitly enabled for incognito mode in Chrome's extension settings. --- # How to edit cookies in Chrome > **TL;DR**: To edit cookies in Chrome, open DevTools (F12) → Application → Cookies, then double-click any cell to change value, expiry, SameSite, HttpOnly, or Secure flags. For a faster workflow without DevTools, install CookieVault Editor and edit cookies inline from the toolbar popup. Both methods modify the cookie store immediately. Editing cookies in Chrome is a browser operation that lets you modify the value, expiration, domain, path, and security flags of any cookie stored for a given site. The primary use cases are debugging session bugs, testing per-flag behavior (SameSite, Secure, HttpOnly), reproducing user-reported issues, and extending session lifetimes during development. Chrome provides two reliable methods — the built-in DevTools Application panel and a Manifest V3 extension — each suited to different workflows[^1]. ## Quick comparison: DevTools vs extension > **In short**: DevTools is built in and requires no installation but demands multiple clicks per edit. An extension offers a faster, repeatable workflow from the toolbar — especially when editing cookies across multiple domains or making the same change repeatedly. | Capability | DevTools (built-in) | CookieVault Editor (extension) | | --------------------------------- | ---------------------------------------------------- | ----------------------------------------- | | Edit cookie value | Yes — double-click cell | Yes — inline field | | Edit expiry / Max-Age | Yes — double-click cell | Yes — date picker | | Edit SameSite / Secure / HttpOnly | Yes — double-click cell | Yes — toggle switches | | Edit cookies for other domains | Only if that domain set a cookie on the current page | Yes — any domain via `chrome.cookies` API | | Create a new cookie | Yes — click empty row at bottom | Yes — "Add cookie" button | | Export before editing (backup) | No | Yes — JSON / Netscape / HAR | | Batch edit multiple cookies | No | Yes — multi-select + bulk edit | | Works in incognito | Yes | Yes (if enabled for incognito) | The Chrome DevTools Application panel documentation describes the cookie table as "an editable spreadsheet" for inspecting and modifying cookies during development[^1]. For production debugging and QA workflows that involve repeated edits, an extension reduces the number of steps per edit from six to two. ## Method 1: Chrome DevTools (the built-in path) > **In short**: DevTools gives you direct access to every cookie attribute in a table format. Double-click any cell to edit. The change applies to the cookie store immediately — reload the page to see the server-side effect. Eight steps from opening DevTools to verified edit. The eight-step DevTools cookie editing workflow: 1. **Open the target website** — navigate to the site whose cookies you want to edit. The cookies must already exist in your browser's store for that domain. 2. **Open Chrome DevTools** — press `F12` (or `Ctrl+Shift+I` on Windows/Linux, `Cmd+Option+I` on Mac). You can also right-click anywhere on the page and choose "Inspect." 3. **Navigate to the Application tab** — click "Application" in the DevTools top bar. If the tab is not visible, click the chevron (`>>`) to expand the overflow menu. 4. **Expand Cookies in the left sidebar** — under "Storage," expand "Cookies." You will see the main domain plus any third-party domains that set cookies on this page. 5. **Click the target domain** — the main panel displays a table showing Name, Value, Domain, Path, Expires, Size, HttpOnly, Secure, SameSite, and Priority. 6. **Double-click any cell to edit** — the cell becomes an input field. Change the value and press Enter. Editable fields include Value, Expires/Max-Age, Domain, Path, SameSite, Secure, and HttpOnly. 7. **Press Enter to commit** — the cookie store updates immediately. No confirmation dialog; no undo. 8. **Reload the page to verify** — press `F5`. The site now receives the modified cookie on the next request. Confirm the expected behavior. > **Important**: Editing the Name field does not rename the cookie — it deletes the old cookie and creates a new one with the new name. If you only want to change the value, leave the Name field untouched. ## Method 2: CookieVault Editor (extension) > **In short**: CookieVault Editor provides a toolbar popup with inline editing — click a cookie, change a field, click Save. No DevTools required. The extension uses Chrome's `chrome.cookies` API, which means it can edit HttpOnly cookies and access cookies for any domain, not just the current page. The eight-step extension workflow: 1. Check the [download page](/en/download/?product=editor) for the verified Editor release status. The package is not yet publicly available. 2. **Navigate to the target site** — open the site whose cookies you want to edit. 3. **Click the toolbar icon** — the popup lists all cookies for the current domain, grouped by first-party and third-party. 4. **Click a cookie name** — the detail view opens, showing Value, Domain, Path, Expires, SameSite, Secure, HttpOnly, and Size. 5. **Edit the fields** — change any field inline. SameSite, Secure, and HttpOnly are toggle switches. Expires has a date picker. Value is a text input. 6. **Click Save** — the extension writes the updated cookie via `chrome.cookies.set()`. The change applies immediately. 7. **Verify** — reload the page or observe the network panel to confirm the modified cookie is sent with the next request. 8. **Optional: export before editing** — for irreversible sessions (banking, admin panels), export to JSON first. If the edit breaks your session, import the backup to restore. The extension workflow is particularly efficient for QA engineers who need to edit cookies on dozens of test domains per day, or for developers testing SameSite behavior across multiple origins. ## Common cookie editing scenarios > **In short**: The most frequent reasons to edit a cookie are extending a session, testing SameSite behavior, simulating a different user, and debugging CSRF token mismatches. Each scenario maps to a specific field edit. Six practical scenarios where editing cookies is the right debugging technique: - **Extend a session during debugging** — double-click the Expires cell and set a date far in the future (e.g., one year from now). This prevents the session from expiring while you step through code. Useful when debugging long multi-step forms. - **Test SameSite behavior** — change SameSite from `Lax` to `Strict` to verify that cross-site navigation breaks authentication as expected. Change to `None` (with Secure = true) to confirm cross-origin iframe embedding works. - **Simulate a different user** — copy a session cookie value from one browser profile and paste it into another. This reproduces the exact session state without re-authenticating. Only works if the server does not bind sessions to IP or User-Agent. - **Debug CSRF token mismatches** — CSRF tokens are often stored in cookies (`csrftoken`, `XSRF-TOKEN`). Editing the cookie value to a known-bad value confirms that the server rejects the request, validating CSRF protection. - **Force a cookie to Secure-only** — set the Secure flag to true on a cookie and verify that the site breaks when loaded over HTTP. This confirms that the site handles the Secure flag correctly in mixed-content scenarios. - **Test cookie path scoping** — change the Path from `/` to `/admin` and verify that the cookie is no longer sent on requests to `/dashboard`. This validates path-scoped cookie behavior. ## Editable cookie attributes reference > **In short**: Chrome exposes eight editable attributes per cookie. Each attribute controls a different aspect of when, where, and how the cookie is sent. Understanding them is essential for effective debugging. | Attribute | What it controls | Example edit | | --------------------- | ----------------------------------------------- | ------------------------------------------------------------ | | **Value** | The data payload sent to the server | Change a session ID to test session fixation | | **Domain** | Which domains receive the cookie | Change `.example.com` to `app.example.com` to restrict scope | | **Path** | Which URL paths receive the cookie | Change `/` to `/api` to limit transmission | | **Expires / Max-Age** | When the cookie is deleted by the browser | Extend to test long-lived sessions | | **Secure** | Cookie is only sent over HTTPS | Toggle to test mixed-content behavior | | **HttpOnly** | Cookie is inaccessible to `document.cookie` | Toggle to test XSS cookie theft scenarios | | **SameSite** | Cross-site sending rules (Strict / Lax / None) | Change to test CSRF and iframe embedding | | **Priority** | Eviction order when the cookie limit is reached | Change to Low to test which cookies Chrome drops first | The Chromium project enforces a limit of approximately 180 cookies per domain. When this limit is reached, Chrome evicts cookies in order of Priority (Low first, then Medium, then High), and within each priority level by least-recently-accessed timestamp[^2]. ## Limitations and edge cases > **In short**: Some cookie edits are constrained by browser security policies. Understanding these limits prevents wasted debugging time. - **Cross-origin cookies** — you cannot edit cookies for a domain that has not set a cookie on the current page (in DevTools). Use an extension for cross-domain access. - **Partitioned cookies (CHIPS)** — Chrome's partitioned cookies feature means the same cookie name can have different values depending on the top-level site. Editing one partition does not affect the others. - **Server-side validation** — changing a session cookie's value to an arbitrary string will fail server-side validation. The server treats the modified value as an invalid session and issues a new cookie on the next response. - **Cookie size limits** — a single cookie cannot exceed approximately 4,096 bytes (name + value combined). DevTools will silently truncate values that exceed this limit. - **`__Host-` and `__Secure-` prefixes** — cookies with these name prefixes are subject to additional restrictions. A `__Host-` prefixed cookie must have Secure = true, Path = `/`, and no Domain attribute. Editing these attributes to violate the prefix rules causes Chrome to reject the cookie. - **Third-party cookie deprecation** — as Chrome phases out third-party cookies, editing third-party cookies in DevTools may show warnings or have no effect for sites enrolled in the Privacy Sandbox. ## See also - [How to delete cookies in Chrome](/en/how-to/delete-cookies-chrome/) — remove cookies entirely instead of editing them - [How to export Chrome cookies to JSON](/en/how-to/export-cookies-json/) — backup cookies before editing as a rollback path - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) — selective deletion while preserving sessions - [Auto-delete cookies on tab close](/en/how-to/auto-delete-on-tab-close/) — automated cleanup for privacy - [CookieVault Editor](/en/editor/) — the open-source Manifest V3 cookie editor for Chrome - [What is a cookie?](/en/concepts/what-is-a-cookie/) — the underlying HTTP cookie protocol explained --- [^1]: Chrome's official DevTools documentation for cookie inspection, editing, and deletion is at https://developer.chrome.com/docs/devtools/storage/cookies. The Application panel's cookie table supports inline editing of all standard cookie attributes. [^2]: Chromium's cookie storage limits and eviction behavior are documented in the Chromium source code and discussed in the Chrome Platform Status entries for cookie-related features. The approximate limit of 180 cookies per domain and the priority-based eviction order are implementation details that have been stable across Chrome versions. ### how-to/en/export-cookies-json.md --- title: 'How to export Chrome cookies to JSON or Netscape format' slug: export-cookies-json description: 'How to export Chrome cookies to JSON, Netscape cookies.txt, or HAR format. Covers DevTools, extensions, and command-line workflows for backup or test fixtures.' type: how-to locale: en cluster: task author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-19 lastUpdated: 2026-08-10 primaryKeyword: export chrome cookies json secondaryKeywords: - export cookies to netscape format - backup chrome cookies - chrome cookies to curl - export cookies for testing - save cookies json file intent: informational funnel: mofu schemaType: - HowTo - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true howToSteps: - name: Decide which cookies to export text: Determine whether you need cookies for one specific domain (e.g., staging.example.com) or all cookies across every domain. Single-domain exports are smaller and easier to share; full exports are better for complete browser-state backups. - name: Choose an export format text: Pick the format that matches your downstream tool. JSON for structured data and re-import, Netscape cookies.txt for curl/wget/Playwright, HAR for full request archives including headers and response bodies. - name: Install CookieVault Editor text: 'Check the [download page](/en/download/?product=editor) for the verified Editor release status. The package is not yet publicly available.' - name: Open the extension popup text: Navigate to the target site (or any page if exporting all cookies). Click the CookieVault Editor toolbar icon. The popup displays all cookies for the current domain, or click "All cookies" to see every cookie in the browser. - name: Click Export text: Click the "Export" button in the popup toolbar. A format picker appears — select JSON, Netscape cookies.txt, or HAR. - name: Save the file text: Chrome opens a file-save dialog. Choose a location and filename. For JSON exports, the file uses a `.json` extension; for Netscape format, `.txt`; for HAR, `.har`. - name: Verify the export text: Open the saved file in a text editor or JSON viewer. Confirm that the expected cookies are present, including HttpOnly cookies that are not visible to `document.cookie`. Check that domain, path, expiry, and flag values are correct. - name: Use the exported file text: Feed the export to your downstream tool — `curl -b cookies.txt`, Playwright's `context.addCookies()`, or CookieVault Editor's Import function for restoring sessions on another machine or browser profile. faq: - q: Does Chrome DevTools have a built-in cookie export feature? a: No. Chrome DevTools lets you view and edit cookies in the Application panel, but it does not offer an export button. You can manually copy rows from the table, but field types, flags (HttpOnly, Secure, SameSite), and expiry dates are not preserved in a structured format. A Manifest V3 extension like CookieVault Editor provides true one-click export. - q: What is the difference between JSON and Netscape cookies.txt format? a: JSON exports cookies as structured objects with typed fields (domain, path, value, expiry as Unix timestamp, boolean flags). Netscape cookies.txt is a tab-separated plain text format originally designed for Netscape Navigator and still used by curl, wget, and some testing tools. JSON is better for programmatic processing; Netscape is better for command-line tool compatibility. - q: Can I export HttpOnly cookies? a: Yes, but only via DevTools or a Manifest V3 extension. The HttpOnly flag prevents JavaScript (`document.cookie`) from reading the cookie, but DevTools and extensions that use the `chrome.cookies` API have privileged access and can export HttpOnly cookies. A JavaScript-based export snippet running in the page context will miss all HttpOnly cookies. - q: How do I use exported cookies with curl? a: Export in Netscape cookies.txt format, then use `curl -b cookies.txt https://example.com`. curl reads the file and sends the matching cookies with each request. This is useful for scripting authenticated API calls or reproducing session-specific bugs from the command line. - q: Can I import exported cookies into a different browser or profile? a: Yes. CookieVault Editor's Import function reads JSON and Netscape formats and writes each cookie to the target browser's cookie store via `chrome.cookies.set()`. This works across Chrome profiles and on any Chromium-based browser (Edge, Brave, Arc). For Firefox, you need a Firefox-compatible extension that reads the same format. - q: Do exported cookies include third-party cookies? a: It depends on the export scope. A per-domain export includes only cookies for the selected domain. An "All cookies" export includes every cookie in the browser, including third-party cookies set by embedded iframes, ad networks, and analytics providers. Be cautious when sharing all-cookies exports — they may contain session tokens for sensitive sites. - q: How large is a typical cookie export file? a: A single-domain export is usually under 10 KB. A full browser export varies widely — a browser with cookies from 500 domains might produce a JSON file of 200-500 KB. The Netscape format produces slightly smaller files because it omits metadata fields. HAR files are much larger because they include full request and response data. - q: Can I automate cookie exports on a schedule? a: CookieVault Editor does not currently support scheduled exports, but you can automate exports using a headless Chrome setup with Puppeteer or Playwright. Both frameworks expose a `page.cookies()` or `context.cookies()` method that returns the cookie array as JSON. Run the script on a cron schedule and write the output to a file or object store. --- # How to export Chrome cookies to JSON > **TL;DR**: To export Chrome cookies to JSON, install CookieVault Editor, click Export, and choose JSON (or Netscape cookies.txt for curl/wget). Chrome DevTools does not have a built-in export feature. For automated exports in CI/CD, use Puppeteer's `page.cookies()` or Playwright's `context.cookies()`. Exporting Chrome cookies to JSON is the process of serializing the browser's cookie store into a structured file that can be backed up, shared, imported into another browser profile, or fed to command-line tools like `curl` and `wget`. Chrome's DevTools Application panel lets you view and edit cookies but does not offer an export button — a Manifest V3 extension or a headless browser script is required for structured export[^1]. This guide covers three methods in order of practicality for different workflows. ## Quick comparison: export methods > **In short**: Use a Manifest V3 extension for interactive one-click exports. Use Puppeteer or Playwright for automated exports in CI/CD pipelines. Use the DevTools console for quick one-off grabs when you cannot install an extension, keeping in mind that HttpOnly cookies will be missing. | Method | Exports HttpOnly cookies | Output format | Automation support | Requires extension | | ---------------------------------- | ---------------------------- | --------------------------- | -------------------------- | ---------------------- | | CookieVault Editor (extension) | Yes | JSON, Netscape, HAR | No (manual click) | Yes | | Puppeteer `page.cookies()` | Yes | JSON (via `JSON.stringify`) | Yes (scriptable, CI-ready) | No (headless Chrome) | | Playwright `context.cookies()` | Yes | JSON (via `JSON.stringify`) | Yes (scriptable, CI-ready) | No (headless Chromium) | | DevTools console `document.cookie` | No (misses HttpOnly) | Raw string (manual parsing) | No | No | | HAR export via DevTools Network | Partial (in request headers) | HAR | No | No | According to the Chrome DevTools documentation, the Application panel's cookie table is designed for inspection and editing, not for data export[^1]. The Network panel can export full request archives as HAR files that include cookie headers, but extracting individual cookies from HAR requires post-processing. ## Method 1: CookieVault Editor (recommended) > **In short**: CookieVault Editor exports cookies from a toolbar popup in three formats — JSON for structured data, Netscape cookies.txt for curl/wget, and HAR for full request archives. One click per export, including HttpOnly cookies. The eight-step export workflow: 1. **Decide which cookies to export** — determine whether you need a single-domain export (e.g., `staging.example.com`) or a full browser export. Single-domain exports are smaller and safer to share; full exports capture your entire session state. 2. **Choose an export format** — JSON for programmatic use and re-import. Netscape cookies.txt for `curl -b` and `wget --load-cookies`. HAR for full request archives including headers and response bodies. 3. Check the [download page](/en/download/?product=editor) for the verified Editor release status. The package is not yet publicly available. 4. **Open the extension popup** — click the CookieVault Editor toolbar icon. The popup shows all cookies for the current domain. Click "All cookies" to see every cookie in the browser. 5. **Click Export** — the format picker appears. Select JSON, Netscape cookies.txt, or HAR. 6. **Save the file** — Chrome opens a file-save dialog. Choose a location and filename. 7. **Verify the export** — open the file in a text editor or JSON viewer. Confirm that the expected cookies are present and that HttpOnly cookies are included. 8. **Use the exported file** — feed it to your downstream tool: `curl -b cookies.txt`, Playwright's `context.addCookies()`, or CookieVault Editor's Import function for cross-profile session transfer. > **Important**: Exported cookie files contain authentication tokens. Treat them like passwords — do not commit them to version control, do not share them over unencrypted channels, and delete them when no longer needed. ## Method 2: Puppeteer or Playwright (automated) > **In short**: For CI/CD pipelines, test fixture generation, and scripted workflows, Puppeteer's `page.cookies()` and Playwright's `context.cookies()` return the cookie array as JSON. Both include HttpOnly cookies. Write the output to a file with `JSON.stringify`. A minimal Puppeteer export script: ```javascript const puppeteer = require('puppeteer'); const fs = require('fs'); (async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://example.com'); // Authenticate if needed (page.type, page.click, etc.) const cookies = await page.cookies(); fs.writeFileSync('cookies.json', JSON.stringify(cookies, null, 2)); await browser.close(); })(); ``` The equivalent Playwright approach: ```javascript const { chromium } = require('playwright'); const fs = require('fs'); (async () => { const browser = await chromium.launch(); const context = await browser.newContext(); const page = await context.newPage(); await page.goto('https://example.com'); const cookies = await context.cookies(); fs.writeFileSync('cookies.json', JSON.stringify(cookies, null, 2)); await browser.close(); })(); ``` Both methods return an array of cookie objects with typed fields: `name`, `value`, `domain`, `path`, `expires` (Unix timestamp), `httpOnly`, `secure`, `sameSite`. The output is directly compatible with `context.addCookies()` for re-import. ## Method 3: DevTools console (limited) > **In short**: Running `document.cookie` in the DevTools console returns a semicolon-separated string of cookie name=value pairs for the current domain. This method is fast but incomplete — HttpOnly cookies are excluded and metadata (expiry, flags, path) is lost. The `document.cookie` approach works as a quick fallback when you cannot install an extension: 1. Open DevTools (`F12`) → Console tab 2. Type `document.cookie` and press Enter 3. Copy the output string 4. Parse manually or use a script to split on `; ` and then on `=` This method has three significant limitations: - HttpOnly cookies are invisible to JavaScript — they are excluded from `document.cookie` - Cookie metadata (expiry, SameSite, Secure, HttpOnly, Path, Domain) is not included - Third-party cookies set by other domains are not accessible from the current page's JavaScript context For anything beyond a quick sanity check, use Method 1 or Method 2. ## Export format reference > **In short**: JSON and Netscape are the two most common export formats. JSON preserves all metadata and is re-importable. Netscape is a legacy format designed for curl/wget compatibility. HAR is a full-request archive that includes cookies as part of the HTTP headers. ### JSON format ```json [ { "name": "session_id", "value": "abc123def456", "domain": ".example.com", "path": "/", "expires": 1756252800, "httpOnly": true, "secure": true, "sameSite": "Lax" } ] ``` JSON advantages: - Typed fields (boolean for flags, number for expiry) - Directly compatible with Puppeteer/Playwright `addCookies()` - Schema-validatable - Human-readable and diffable - Supports nested structures for grouping by domain ### Netscape cookies.txt format ``` # Netscape HTTP Cookie File .example.com TRUE / TRUE 1756252800 session_id abc123def456 ``` Each line has seven tab-separated fields: domain, include subdomains (TRUE/FALSE), path, secure (TRUE/FALSE), expiry (Unix timestamp), name, value. Netscape advantages: - Direct compatibility with `curl -b` and `wget --load-cookies` - Compact file size - Supported by virtually every command-line HTTP tool - Simple to parse with shell scripts (`awk`, `cut`) ### When to use which format | Use case | Recommended format | | ------------------------------------------- | ---------------------------- | | Backup and restore across browser profiles | JSON | | Feed cookies to `curl` or `wget` | Netscape cookies.txt | | Share test fixtures with QA team | JSON | | Archive full request/response for debugging | HAR | | Automate in CI/CD with Puppeteer/Playwright | JSON | | Import into Postman or Insomnia | JSON (via collection import) | ## Security considerations for exported cookies > **In short**: Cookie export files are credential-equivalent artifacts. A leaked session cookie file gives anyone full access to your authenticated sessions. Handle them with the same care as passwords and API keys. Six security rules for handling exported cookie files: - Never commit cookie export files to version control — add `*.cookies.json` and `cookies.txt` to `.gitignore` - Do not share exports over unencrypted channels (email, Slack DMs without E2E encryption, public Pastebin) - Delete export files when no longer needed — session cookies in a file remain valid until the server expires the session - Restrict file permissions on shared development machines (`chmod 600 cookies.json` on Linux/Mac) - When sharing test fixtures, replace real session values with placeholder tokens and document the replacement - If an export file is accidentally leaked, invalidate all affected sessions immediately by logging out of the sites and changing passwords These precautions apply equally to JSON, Netscape, and HAR formats — all three contain the raw cookie values that authenticate your sessions. ## See also - [How to delete cookies in Chrome](/en/how-to/delete-cookies-chrome/) — delete cookies after exporting as a backup - [How to edit cookies in Chrome](/en/how-to/edit-cookies-chrome/) — modify cookie values without deleting them - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) — export protected sessions, then clear everything else - [How to whitelist cookies in Chrome](/en/how-to/whitelist-cookies/) — protect specific cookies from deletion - [CookieVault Editor](/en/editor/) — the open-source Manifest V3 extension for viewing, editing, and exporting cookies - [CookieVault Guardian](/en/guardian/) — automated cleanup with whitelist support --- [^1]: Chrome's official DevTools documentation for cookie inspection and editing is at https://developer.chrome.com/docs/devtools/storage/cookies. The Application panel displays cookies in a table with inline editing but does not include an export function. The Network panel's HAR export includes cookies as part of request headers but requires post-processing to extract individual cookie records. ### how-to/en/whitelist-cookies.md --- title: 'How to whitelist cookies in Chrome — Keep logins for trusted sites (2026)' slug: whitelist-cookies description: 'How to whitelist cookies in Chrome — use Chrome built-in exception list or CookieVault Guardian for richer per-domain, subdomain-inherited, wildcard-supported cookie allowlisting.' type: how-to locale: en cluster: task author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: whitelist cookies chrome secondaryKeywords: - chrome cookie exception list - keep cookies for specific sites - cookie allowlist chrome - whitelist cookies extension - chrome always allow cookies site intent: informational funnel: mofu schemaType: - HowTo - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true howToSteps: - name: Open Chrome Settings text: Click the three-dot menu → Settings, or type chrome://settings in the address bar. - name: Navigate to Privacy and security → Cookies text: In the left sidebar choose "Privacy and security", then "Cookies and other site data." - name: Scroll to "Customized behaviors" text: Below the general cookie controls you will find "Sites that can always use cookies", "Sites that can never use cookies", and "Sites that always clear cookies when you close them." - name: Click "Add" under "Sites that can always use cookies" text: Enter the domain you want to whitelist. Use the [*.] prefix for subdomain inheritance — for example, [*.]example.com covers example.com, www.example.com, and mail.example.com. - name: Save and verify text: Close the dialog. The domain now appears in the list. Visit the site, log in, close Chrome entirely, reopen — you should still be logged in on that site even if "Clear cookies on exit" is enabled. - name: Repeat for additional sites text: Add every site whose login you want to preserve. A practical starter set — email provider, bank, code host, work tools, password manager web UI. - name: For per-tab cleanup, use CookieVault Guardian instead text: Chrome's built-in whitelist only exempts from "Clear on exit." If you want auto-delete on tab close (not just on exit), install CookieVault Guardian and configure its whitelist — it supports the same per-domain rules plus wildcards and greylist. - name: Test by visiting a non-whitelisted site text: After whitelisting your trusted sites, browse a non-whitelisted site, close the tab (with Guardian) or close Chrome (with built-in), then reopen. The non-whitelisted site's cookies should be gone; your whitelisted sites should remain logged in. faq: - q: What does "whitelist cookies" mean? a: Whitelisting cookies means adding a domain to an exception list so that its cookies (and optionally other site data) are preserved even when you clear cookies for everything else — manually, on browser exit, or on tab close via an extension. - q: Does Chrome have a built-in cookie whitelist? a: Yes, partially. Under Settings → Privacy → Cookies → "Sites that can always use cookies" you can add domains. This whitelist exempts those domains from the "Clear on exit" toggle and from third-party cookie blocking. It does not affect per-tab auto-delete extensions. - q: What is the difference between Chrome's built-in whitelist and Guardian's whitelist? a: Chrome's whitelist only exempts from "Clear on exit" and third-party blocking. Guardian's whitelist exempts from per-tab auto-delete, covers all storage types (cookies + localStorage + IndexedDB + Cache + Service Workers), supports wildcard patterns, and syncs across devices in Pro. - q: How do I whitelist subdomains? a: In Chrome's built-in, prefix the domain with [*.] — for example, [*.]google.com. In Guardian, subdomain inheritance is on by default when you add a domain; you can disable it per rule if needed. - q: Will whitelisting a site let it track me? a: Whitelisting keeps the site's cookies alive, which means the site can maintain your session and preferences — and also track you across visits if it chooses. Only whitelist sites you trust. Trackers embedded on other sites (third-party cookies) are controlled by Chrome's third-party cookie policy, not by your whitelist. - q: What is the greylist? a: CookieVault Guardian's greylist is a middle ground — "keep for this session, clean next time." Useful for sites you visit occasionally where you want session continuity but no long-term cookie persistence. Chrome's built-in does not have an equivalent. - q: Can I export my whitelist? a: Chrome's built-in does not have export/import. CookieVault Guardian does — Settings → Export → JSON. This is useful when setting up a new device or syncing manually across browsers that don't use the same account. - q: How many sites should I whitelist? a: As few as possible. A typical user needs 5-10 entries (email, bank, code host, work tools, password manager). Every additional entry is a domain whose cookies persist across sessions, so keep the list tight and review it periodically. --- # How to whitelist cookies in Chrome > **TL;DR**: Chrome has a built-in "Sites that can always use cookies" exception list under Settings → Privacy → Cookies. For richer whitelist behavior — subdomain inheritance, wildcard patterns, greylist, and per-tab auto-delete exemption — use CookieVault Guardian's whitelist instead. Whitelisting cookies in Chrome is the practice of exempting specific trusted domains from any cookie-clearing policy — whether that is Chrome's built-in "Clear on exit," a manual bulk delete, or a per-tab auto-delete extension. The goal is simple: keep logins for the sites you use daily while everything else gets cleaned. ## Two approaches compared > **In short**: Chrome's built-in whitelist is adequate for "Clear on exit" users. Guardian's whitelist is the upgrade for users who want per-tab cleanup, broader storage coverage, wildcard support, and cross-device sync. | Feature | Chrome built-in whitelist | CookieVault Guardian whitelist | | -------------------------------- | ------------------------- | ------------------------------ | | Exempts from "Clear on exit" | Yes | N/A (Guardian is per-tab) | | Exempts from per-tab auto-delete | No | Yes | | Subdomain inheritance | Manual ([*.] prefix) | On by default | | Wildcard patterns | No | Yes (\*.googleapis.com etc.) | | Greylist (session-only) | No | Yes | | Covers localStorage / IndexedDB | No | Yes | | Cross-device sync | No | Yes (Pro) | | Export / Import | No | Yes (JSON) | ## Method 1: Chrome built-in whitelist > **In short**: Settings → Privacy → Cookies → "Sites that can always use cookies" → Add. Works for "Clear on exit" exemption; does not work with per-tab extensions. Eight steps: 1. Open Chrome Settings (three-dot menu → Settings) 2. Navigate to Privacy and security → Cookies and other site data 3. Scroll to "Customized behaviors" 4. Click "Add" under "Sites that can always use cookies" 5. Enter the domain with `[*.]` prefix for subdomain inheritance (e.g., `[*.]example.com`) 6. Save 7. Repeat for email, bank, code host, work tools, password manager 8. Test: enable "Clear on exit," close Chrome, reopen — whitelisted sites should remain logged in **Limitation**: this whitelist only affects Chrome's own "Clear on exit" and third-party cookie blocking. It does not exempt domains from per-tab auto-delete extensions like Guardian. ## Method 2: CookieVault Guardian whitelist > **In short**: Install Guardian → visit site → click toolbar icon → "Add to whitelist." Subdomain inheritance is on by default. Wildcard patterns for advanced rules. Greylist for session-only keep. Six steps: 1. Download the verified Guardian ZIP from the [download page](/en/download/?product=guardian) and follow the manual installation steps; store listings are not yet available. 2. Visit a site you trust (Gmail, GitHub, your bank) 3. Click the Guardian toolbar icon → "Add to whitelist" 4. The domain and its subdomains are automatically exempted from tab-close cleanup 5. For advanced rules, open Settings → Whitelist and add wildcard entries (e.g., `*.googleapis.com`) 6. Use the greylist button for sites you want to keep this session but clean next time ## Recommended starter whitelist A five-entry baseline that covers most users: - Primary email (Gmail / Outlook / Proton) - Code host (GitHub / GitLab) - Work tools (Linear, Notion, Slack, Figma — whichever you use) - Bank - Password manager web UI (1Password / Bitwarden) Everything else: clean on tab close (Guardian) or clean on browser exit (Chrome built-in). ## See also - [Auto-delete cookies on tab close](/en/how-to/auto-delete-on-tab-close/) — the Guardian setup guide - [Clear cookies but stay logged in](/en/how-to/clear-cookies-but-stay-logged-in/) — selective deletion for a one-off cleanup - [Cookie whitelist feature](/en/features/cookie-whitelist/) — deep dive on Guardian's whitelist architecture - [CookieVault Guardian](/en/guardian/) — product overview - [How to delete cookies in Chrome](/en/how-to/delete-cookies-chrome/) — manual deletion methods - [What is a cookie?](/en/concepts/what-is-a-cookie/) — the underlying protocol ### pages/en/about.md --- title: 'About CookieVault — Mission, team, and open-source philosophy' slug: about description: 'CookieVault is an independent, open-source browser-privacy team building cookie tools with no ads and no data sale. Our mission, funding model, and team.' type: landing locale: en cluster: privacy author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-07-15 primaryKeyword: about cookievault secondaryKeywords: - cookievault company - cookievault team - cookievault mission - open source privacy company intent: informational funnel: tofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Who makes CookieVault? a: CookieVault is built by a small, independent team of open-source developers with backgrounds in browser-extension engineering, applied cryptography, and privacy research. Founder and reviewer profiles are on the team pages, with verified social links published before public launch. - q: How is CookieVault funded? a: By Pro subscriptions, and nothing else. There is no venture capital, no advertising, no data sale, and no telemetry-based revenue. The free tier is funded by people who choose to pay for the Pro sync tier, which keeps the incentives aligned with users rather than advertisers. - q: Is CookieVault a registered company? a: The operating entity is being formalized ahead of public launch; the registration jurisdiction is Malaysia. We disclose this on the privacy page because it affects data-protection jurisdiction and, for users in mainland China, access stability (we do not file for mainland ICP registration). - q: Why should I trust a cookie extension? a: You should not trust any cookie extension on its word — you should verify. CookieVault publishes both extensions' full source under the MIT license, ships reproducible builds so the store binary can be checked against a Git commit, runs zero telemetry, and documents its security model openly. Trust is meant to be earned through verifiability, not asserted. - q: Does CookieVault sell my data? a: No, never. We have a formal, permanent no-sale pledge that covers all user data under CCPA, GDPR, and other frameworks. The pledge is binding on any future acquirer. See the no-sale pledge page for the full commitment. - q: How can I contact or contribute to CookieVault? a: Email support@cookievault.net for help, security@cookievault.net for vulnerability disclosure, and press@cookievault.net for media. For code contributions, the repositories are public on GitHub under the MIT license — read CONTRIBUTING.md and open a discussion before large pull requests. --- # About CookieVault > **TL;DR**: CookieVault is a small, independent team building open-source browser-privacy tools. We run no ads, sell no data, and publish both extensions' full source under the MIT license. We are funded by Pro subscriptions and nothing else. CookieVault is an independent open-source project founded in 2026 to fill the gap left by EditThisCookie and Cookie AutoDelete — two trusted cookie extensions that became unavailable within months of each other. We build modern Manifest V3 extensions with end-to-end encrypted sync, fully open source, on a business model that does not depend on tracking the people who use them. ## What we believe > **In short**: Cookies are user infrastructure, and the tools to manage them should be open-source, auditable, and trustworthy. A privacy tool that monetizes your data has its incentives backwards. Three principles drive every decision: - **Auditability over assertion** — we publish the code and ship reproducible builds so you can verify our claims rather than take them on faith. - **Alignment over extraction** — funded by subscriptions, not advertising, so the product improves for users instead of for advertisers. - **Honesty over hype** — our comparison pages name competitors' genuine strengths, our footnotes link real sources, and our placeholders are labeled as placeholders. ## Who we are > **In short**: A small team — founder, engineering, and an independent security reviewer — with backgrounds in browser engineering, applied cryptography, and privacy research. Real bios and verified links publish before launch. The founders are independent open-source developers with a combined background in browser-extension engineering, applied cryptography, and privacy research. Technical content is reviewed by a separate security reviewer before publication, per our two-reviewer standard for anything touching the cryptographic or cookie-handling boundary. Full profiles live on the team pages: - [Lena Park — Founder & CEO](/en/team/lena-park/) - [Marcus Reiter — Security Reviewer](/en/team/marcus-reiter/) ## How we are funded > **In short**: Pro subscriptions only. No VC, no ads, no data sale, no telemetry revenue. The incentive is to make a tool worth paying for, not to harvest the free tier. | Revenue source | Used? | Why | | -------------------------- | ----- | --------------------------------- | | Pro / Team subscriptions | Yes | Aligns incentives with users | | Venture capital | No | Avoids pressure to monetize data | | Advertising | No | Conflicts with a privacy product | | Data sale / licensing | No | Forbidden by our no-sale pledge | | Telemetry / analytics SDKs | No | The extension ships zero trackers | ## Where to find us GitHub for code, email for support and disclosure, and the team pages for who we are. Full channels on the [contact page](/en/contact/). ## See also - [Open source](/en/open-source/) — repositories, license, reproducible builds - [Security](/en/security/) — encryption design and disclosure policy - [No-sale pledge](/en/no-sale-pledge/) — our permanent data commitment - [Privacy policy](/en/privacy/) — what we collect and never collect - [Contact](/en/contact/) — support, security, press - [Pricing](/en/pricing/) — how the funding model works in practice ### pages/en/contact.md --- title: 'Contact CookieVault — Support, security disclosure, press' slug: contact description: 'Contact CookieVault — support@cookievault.net for help, security@cookievault.net for vulnerability disclosure, press@cookievault.net for media. We reply within one business day.' type: landing locale: en cluster: privacy author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-05-22 primaryKeyword: contact cookievault secondaryKeywords: - cookievault support - cookievault security disclosure - cookievault press intent: navigational funnel: bofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: How do I get support for CookieVault? a: Email support@cookievault.net for installation issues, billing questions, account recovery, and bug reports. We reply within one business day. For reproducible bugs and feature requests, filing a GitHub issue is often faster because the whole community can see the answer. - q: How do I report a security vulnerability? a: Email security@cookievault.net. Our PGP public key is published at /.well-known/security.txt. We follow responsible disclosure with a 90-day standard timeline (accelerated for actively exploited issues) and credit researchers in the release notes. See the security page for the full policy. - q: How do I reach CookieVault for press or media? a: Email press@cookievault.net for interviews, embargoed launches, and comment on Manifest V3 or cookie-policy news. We can speak to the post-EditThisCookie and post-Cookie AutoDelete migration landscape and to privacy-preserving extension design. - q: Do you offer live chat or phone support? a: No. We are a small team and answer email personally rather than running a live chat or phone line. Async email lets us give considered, accurate answers — especially for security and billing questions where precision matters. - q: Where do I request a refund? a: Pro and Team purchases have a 30-day no-questions-asked refund. Request it through the Paddle billing portal or email support@cookievault.net. Paddle is our Merchant of Record and processes refunds directly. - q: How do I delete my account and data? a: Email support@cookievault.net or use the in-account deletion option. Because sync data is end-to-end encrypted, deleting your account removes the opaque ciphertext we hold; the plaintext only ever existed on your devices. See the privacy page for retention details. --- # Contact > **TL;DR**: Email support@cookievault.net for help, security@cookievault.net for vulnerability disclosure (PGP key at /.well-known/security.txt), and press@cookievault.net for media. We are async-only and reply within one business day. Contacting CookieVault is done by email, routed to the right inbox for your need. We are a small team that answers email personally — there is no live chat or phone line — and we aim to reply within one business day. The three addresses below cover support, security, and press; for code, GitHub is the fastest path. ## Choose the right channel > **In short**: Support for help and billing, security for vulnerabilities, press for media, GitHub for bugs and contributions. Using the right channel gets you a faster, more accurate answer. | Need | Channel | Typical response | | --------------------------------------------- | ---------------------------------------- | ----------------------------------- | | Installation, billing, account recovery, bugs | support@cookievault.net | 1 business day | | Security vulnerability disclosure | security@cookievault.net (PGP available) | 1 business day, acknowledged faster | | Press, interviews, embargoed launches | press@cookievault.net | 1-2 business days | | Reproducible bugs, feature requests | GitHub Issues | Public discussion | | Code contributions | GitHub Pull Requests | Reviewed per CONTRIBUTING.md | ## Support > **In short**: support@cookievault.net handles installation, billing, account recovery, and bug reports for both Editor and Guardian, across all six supported browsers. For anything that is not a security or press matter, support@cookievault.net is the right address. To help us resolve faster, include your browser and version, which extension (Editor or Guardian), and the steps to reproduce. For reproducible issues, a GitHub issue lets the whole community benefit from the answer. ## Security disclosure > **In short**: security@cookievault.net, with a PGP key at /.well-known/security.txt. Responsible disclosure: 90-day standard timeline, researcher credit in release notes. We honor responsible disclosure and credit researchers in the release notes. The machine-readable policy is published per RFC 9116 at [/.well-known/security.txt](/.well-known/security.txt), and the full human-readable policy is on the [security page](/en/security/). Please do not open public GitHub issues for security vulnerabilities — email first. ## Press and media > **In short**: press@cookievault.net for interviews and comment. We can speak to the cookie-extension migration landscape and privacy-preserving extension design. We are happy to comment on the post-EditThisCookie and post-Cookie AutoDelete migration story, the Manifest V3 transition's effect on privacy extensions, and how zero-knowledge sync is designed. ## See also - [Security](/en/security/) — full disclosure policy and PGP details - [About](/en/about/) — who we are and how we are funded - [Open source](/en/open-source/) — GitHub repositories and contribution guide - [Privacy policy](/en/privacy/) — how we handle the little data we hold - [Pricing](/en/pricing/) — billing and refunds ### pages/en/download.md --- title: 'Download CookieVault for Chrome' slug: download description: 'Download the verified CookieVault Guardian Chrome package and install it manually while the official store listing is being prepared.' type: landing locale: en cluster: tool author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: download cookievault secondaryKeywords: - install cookievault chrome - cookievault guardian download - install unpacked chrome extension intent: transactional funnel: bofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Can I install CookieVault before the Chrome Web Store listing is live? a: Yes. CookieVault Guardian 0.1.0 is available as a verified Chrome ZIP for manual installation. CookieVault Editor is not yet available because its production sync service must pass release checks first. - q: Which browsers can use the manual package? a: The current package is for Chrome and Chromium-based desktop browsers that support loading an unpacked extension. Firefox and Safari packages are not currently published. - q: Do I need to install both Editor and Guardian? a: No. They are independent. Guardian handles automatic cleanup; Editor handles viewing, editing, importing, and exporting cookies. - q: Is the download free? a: Yes. Installation and local features are free. Pro is optional and checkout is handled through the shared Extensionsly account and billing system. - q: Will a manual install update automatically? a: No. Download the new ZIP and replace the unpacked folder when a new release ships. The official store version will provide automatic updates after approval. - q: How can I verify the package? a: Compare its SHA-256 checksum with the value on the download page. The current Guardian 0.1.0 package checksum is ed6b1174a37032224525387d6023c86cb08444437bbd71256ec7d65019328b72. --- # Download CookieVault CookieVault is not yet published in the Chrome Web Store. The verified manual release currently available is **CookieVault Guardian 0.1.0** for Chrome; **CookieVault Editor is still being prepared** because its production sync service must pass release checks before a public package is issued. ## Current release status | Extension | Status | Version | Package | | -------------------- | --------- | ------- | ------------- | | CookieVault Editor | Preparing | 0.1.0 | Not published | | CookieVault Guardian | Available | 0.1.0 | Chrome ZIP | Guardian’s package is served from the dedicated Extensionsly release origin: `https://downloads.extensionsly.com/extensions/cookievault-guardian/0.1.0/chrome/guardian-0.1.0-chrome.zip` SHA-256: `ed6b1174a37032224525387d6023c86cb08444437bbd71256ec7d65019328b72` ## Install the unpacked extension 1. Download the Guardian ZIP from the download page. 2. Unzip it into a folder you will keep. 3. Open `chrome://extensions`. 4. Turn on **Developer mode**. 5. Choose **Load unpacked** and select the unzipped folder. Manual installations do not update automatically. When a new version ships, download it again and replace the unpacked folder. Move to the official store version after it becomes available. ## Payment and Pro access Installation is free. CookieVault does not collect payment on the download page. Optional Pro purchases hand off to the shared Extensionsly account and billing system, where the order is created and Paddle handles payment. ## See also - [CookieVault Editor](/en/editor/) — cookie manager feature overview - [CookieVault Guardian](/en/guardian/) — auto-delete feature overview - [Pricing](/en/pricing/) — Free and Pro options - [Security](/en/security/) — package and sync security ### pages/en/editor.md --- title: 'CookieVault Editor — Open-source cookie manager for Chrome, Edge, Firefox' slug: editor description: 'CookieVault Editor is a free, MIT-licensed Manifest V3 cookie manager for Chrome, Edge, Brave, Firefox, Opera, Vivaldi, and Arc. Edit, search, export, multi-profile, end-to-end encrypted sync.' type: landing locale: en cluster: tool author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookie manager chrome extension secondaryKeywords: - chrome cookie editor extension - manifest v3 cookie manager - open source cookie manager - editthiscookie replacement - cookie sync extension - browser cookie editor intent: commercial funnel: bofu schemaType: - SoftwareApplication - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What browsers does CookieVault Editor support? a: CookieVault Editor runs on every modern Chromium browser — Chrome, Edge, Brave, Opera, Vivaldi, Arc — using the same Manifest V3 build distributed through the Chrome Web Store. A separate Manifest V3 build for Firefox is published on the Firefox Add-ons site. Source builds for other Chromium-based browsers (such as Whale or Sidekick) work via direct CRX side-load from the GitHub release page. - q: Is CookieVault Editor really free? a: Yes. Free includes unlimited cookie CRUD and search, JSON import/export, 1 local profile, and dark mode, with no time limit. Pro ($3.99/month, $29/year, or $59 lifetime) adds unlimited profiles, one-click switching, encrypted cross-device sync, 90-day history, and CSV/HAR export. - q: How is CookieVault Editor different from EditThisCookie? a: CookieVault Editor is the Manifest V3 successor to EditThisCookie (which was removed from the Chrome Web Store in September 2024). It matches the EditThisCookie editing workflow exactly, then adds three things EditThisCookie never had — end-to-end encrypted cloud sync, cookie history with undo, and reproducible-build provenance from a public GitHub commit. See the [EditThisCookie alternative](/en/alternatives/editthiscookie/) page for the full migration guide. - q: How does the end-to-end encrypted sync work? a: When you create a Pro account, you choose a passphrase. The passphrase is run through PBKDF2-SHA-256 (600,000 iterations) on your device to produce an encryption key. Each cookie record is encrypted with AES-256-GCM (Web Crypto API) before leaving the browser. The CookieVault sync server stores only opaque ciphertext — neither CookieVault staff nor a server compromise can decrypt your cookies. See the [security page](/en/security/) for the full threat model. - q: Does CookieVault Editor send any telemetry or analytics? a: No. The extension ships with zero third-party telemetry SDKs. No Google Analytics, no Mixpanel, no Sentry, no fingerprinting. The only network traffic the extension makes is to the CookieVault sync server (and only if you have explicitly enabled sync on a Pro account). Local-only Free users send nothing. - q: Is the source code really open source? a: Yes — MIT-licensed on GitHub. The Editor and Guardian browser extensions, including the client-side cryptographic boundary, are in public repositories; the hosted sync service remains proprietary. Chrome Web Store releases are tagged in Git, and the binary published to the store is reproducible-built from the tagged commit. You can verify the SHA-256 of the store binary against the tag's CI artifact. - q: Will CookieVault Editor break my logins? a: No. The Editor reads and modifies cookies through the official `chrome.cookies` API, which the browser uses for its own cookie store. Edits go to the same store the browser already reads from. The extension never touches localStorage, IndexedDB, or other site data — only cookies. Editing or deleting a session cookie will log you out of that site (which is the intended behavior); not installing the Editor cannot break logins on its own. - q: Can I switch between work and personal cookies without logging out? a: Yes — the multi-account profiles feature. Free stores 1 named local profile. Pro unlocks unlimited profiles, one-click switching, and encrypted cross-device sync, so a browser window can swap between work, personal, and test identities without a separate browser profile. --- # CookieVault Editor > **TL;DR**: CookieVault Editor is a free, MIT-licensed Manifest V3 browser extension that gives you complete control over the cookies stored by your browser — view, edit, search, export, multi-profile, and end-to-end encrypted sync. Built as the modern replacement for the EditThisCookie extension Google removed from the Chrome Web Store in September 2024. CookieVault Editor is a Manifest V3 browser extension that gives developers, QA engineers, and privacy-aware users full read-write control over the cookies their browser stores. It is open source under the MIT license, ships with zero telemetry, and reproduces the per-site cookie-editor workflow that EditThisCookie users relied on for nearly a decade[^1] — extended with end-to-end encrypted cross-device sync, cookie history with undo, and named multi-account profiles. ## Who CookieVault Editor is for > **In short**: Anyone who needs to view, edit, or move cookies more than occasionally. The three core audiences are developers debugging session and auth flows, QA engineers reproducing user-reported bugs, and privacy-conscious users who want first-class control over the small text records browsers leave behind on their behalf. Four common workflows the Editor optimizes for: - **Frontend / fullstack developers** debugging session bugs, validating SameSite changes, and inspecting third-party iframe cookie behavior - **QA engineers** reproducing customer-reported issues that depend on specific session state, and capturing cookies as test fixtures for Playwright / Puppeteer / Selenium scripts - **Privacy researchers** auditing what cookies a site sets, with what flags, and whether the flags match the site's stated cookie policy - **Anyone who lost their EditThisCookie or Cookiebro workflow** when those extensions stopped being available or stopped being maintained If your job involves looking at the Application → Cookies tab in DevTools more than once a week, the Editor will save you minutes every session. ## What the Editor does > **In short**: Free covers unlimited cookie CRUD and search, JSON import/export, 1 local profile, and dark mode. Pro adds unlimited profiles, one-click switching, CSV/HAR export, encrypted sync, and history. Eight Editor capabilities, in approximate decreasing order of how often a typical user touches them: 1. **View** every cookie for the current site (or all sites) in a sortable, filterable list 2. **Edit** any attribute — Name, Value, Domain, Path, Expires, HttpOnly, Secure, SameSite — with inline validation 3. **Search** across all cookies by name, value, or domain pattern (regex supported in Pro) 4. **Export** to JSON (structured), Netscape `cookies.txt` (for curl / wget), or HAR (for full request archives) 5. **Delete** single cookies, all cookies for a domain, or all cookies matching a pattern 6. **Create** new cookies from scratch with all attributes pre-validated 7. **Switch profiles** — load a saved named cookie snapshot, push the previous one to history 8. **Sync** across devices (Pro) — every cookie change replicates to your other browsers via end-to-end encrypted channels ## Browser support > **In short**: Every modern Chromium browser uses the same Chrome Web Store build (Chrome, Edge, Brave, Opera, Vivaldi, Arc). Firefox uses a separate Manifest V3-compatible build on the Firefox Add-ons site. There are no separate Mac / Windows / Linux builds — extensions are browser-only. | Browser | Source | Notes | | ------- | --------------------- | ----------------------------------------------------- | | Chrome | Chrome Web Store | Primary target; tested on every Chrome stable release | | Edge | Edge Add-ons (or CWS) | Same Chromium build, dual-distributed | | Brave | Chrome Web Store | Same build as Chrome | | Opera | Chrome Web Store | Same build (Opera supports CWS extensions) | | Vivaldi | Chrome Web Store | Same build | | Arc | Chrome Web Store | Same build | | Firefox | Firefox Add-ons | Separate Manifest V3 compatible build | | Safari | Not supported | Safari Web Extensions have a different model | A 2024 StatCounter snapshot[^2] shows the seven browsers above cover roughly 95% of global desktop browser usage, so the combined Chromium + Firefox build set lands the Editor in front of nearly every workflow that needs it. ## Pricing > **In short**: Free forever for local cookie management. $3.99/month, $29/year (39% off), or $59 lifetime for Pro with end-to-end encrypted sync, cookie history, named profiles, and CSV/HAR export. No per-cookie limits. See the [pricing page](/en/pricing/) for the full breakdown. The pricing line is deliberately simple — two tiers, three numbers: - **Free** — unlimited local CRUD and search, JSON import/export, 1 local profile, dark mode. Permanent. No card. - **Pro $3.99/mo, $29/yr, or $59 lifetime** — E2E encrypted cross-device sync, 90-day cookie history with undo, unlimited profiles, one-click switching, and CSV/HAR export. - **Team $8/seat/mo** — centralized billing, audit log, SCIM provisioning, SSO. For QA teams and dev consultancies. The Free tier covers the entire EditThisCookie-equivalent workflow. Pro is only worth the money if you use more than one device and want them to stay in sync, or if you want the safety net of cookie-history undo. ## How CookieVault Editor compares CookieVault Editor sits in the same product space as Cookie-Editor and the (now-removed) EditThisCookie. The honest comparison: - **vs EditThisCookie** — full workflow parity plus E2E sync, but EditThisCookie is no longer installable from the Chrome Web Store. Detailed migration walk-through: [EditThisCookie alternative](/en/alternatives/editthiscookie/). - **vs Cookie-Editor** — both are actively maintained Manifest V3. CookieVault adds open-source code, E2E sync, multi-profile, and cookie history. Cookie-Editor has a smaller install footprint and a slightly faster popup open. Detailed comparison: [CookieVault vs Cookie-Editor](/en/vs/cookie-editor/). - **vs Cookiebro** — Cookiebro is closed-source and has not received a Manifest V3 update; CookieVault is open-source and MV3-native. Detailed comparison: [Cookiebro alternative](/en/alternatives/cookiebro/). ## How to install 1. **Release status** — check the [download page](/en/download/?product=editor); the Editor package is not yet publicly available 2. **Edge Add-ons** — same build, Microsoft store 3. **Firefox Add-ons** — separate Firefox Manifest V3 build 4. **Direct CRX** (Opera / Vivaldi / Arc / Brave / Whale / Sidekick) — download the signed CRX from the GitHub release page and drag it into the extensions page 5. **Build from source** — clone the GitHub repo, run `npm install && npm run build`, load the unpacked extension via `chrome://extensions` → Developer Mode See the [download page](/en/download/) for the actual store links and source URL. ## See also - [CookieVault Guardian](/en/guardian/) — the companion auto-delete extension (Cookie AutoDelete successor) - [Features overview](/en/features/multi-account-profiles/) — detailed pages on multi-profile, encrypted sync, and per-feature deep dives - [Pricing](/en/pricing/) — Free / Pro / Team breakdown - [Security](/en/security/) — E2E encryption design, threat model, audit plan - [Open source](/en/open-source/) — MIT license, reproducible builds, contribution guide - [Download](/en/download/) — store links for all six supported browsers --- [^1]: EditThisCookie was the dominant Chrome cookie editor for nearly a decade before being removed from the Chrome Web Store on 2024-09-28 following a maintainer-account transfer incident. See our [EditThisCookie alternative](/en/alternatives/editthiscookie/) page for the full timeline with footnoted sources. [^2]: Cross-browser desktop usage shares are tracked publicly by StatCounter (search "StatCounter desktop browser market share"). StatCounter blocks automated HEAD / GET probes, so we do not link a deep URL that would link-rot in our footnote checker; the rolling 12-month chart from the StatCounter site is the canonical reference. The "Chromium browsers + Firefox cover ~95% of desktop" claim is approximate and varies month to month. ### pages/en/guardian.md --- title: 'CookieVault Guardian — Auto-delete cookies on tab close (Manifest V3)' slug: guardian description: 'CookieVault Guardian is a free, open-source Manifest V3 extension that auto-deletes cookies, localStorage, IndexedDB, and Cache on tab close. The Cookie AutoDelete successor for Chrome, Edge, Firefox.' type: landing locale: en cluster: tool author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: auto delete cookies extension chrome secondaryKeywords: - cookie autodelete chrome alternative - auto clear cookies tab close - manifest v3 cookie cleaner - automatically delete cookies - cookie autodelete manifest v3 - whitelist cookies extension intent: commercial funnel: bofu schemaType: - SoftwareApplication - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What does CookieVault Guardian actually delete? a: Cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations — every browser-storage API that can hold cross-session state. Each storage type is individually toggleable in settings. Guardian cleans these per-domain the moment the last tab on that domain closes, except for domains on your whitelist. - q: How is Guardian different from Cookie AutoDelete? a: Guardian is the Manifest V3 successor to Cookie AutoDelete (which Chrome force-disabled in late 2024 with the MV2 sunset). It matches Cookie AutoDelete's whitelist / greylist / wildcard model exactly, then extends the cleanup scope from "cookies only" to every browser-storage API. Cookie AutoDelete remains installable on Firefox; on Chromium browsers Guardian is the path forward. See [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/). - q: Will Guardian break websites I depend on? a: It will if those sites store important state client-side (drafts in online editors, PWA offline caches, JS framework state caches) and you have not whitelisted them. The fix is straightforward — visit the site, click the Guardian toolbar icon, "Add to whitelist". Subdomain inheritance is on by default, so a single `example.com` whitelist entry covers `mail.example.com` automatically. - q: Is the whitelist synced across my devices? a: Local-only in the Free tier; end-to-end encrypted cross-device sync in Pro ($3.99/month). Sync uses the same crypto stack as CookieVault Editor — passphrase-derived key, AES-256-GCM ciphertext, server stores only opaque blobs. - q: Does Guardian work in Firefox? a: Yes. Firefox kept Manifest V2 support, so Cookie AutoDelete also still works on Firefox. The reason to use Guardian on Firefox is the cross-browser whitelist sync — if you use Firefox + Chrome + Edge, Guardian keeps a single shared rule set, while Cookie AutoDelete is local-only. - q: Will Guardian clear my saved passwords? a: No. Saved passwords live in the browser's password manager (a separate subsystem), not in any of the cookie / localStorage / IndexedDB stores Guardian cleans. Closing a tab on `example.com` clears Guardian's targeted storage types for `example.com` and never touches the password manager entry for that site. - q: What is the greylist for? a: The greylist is the middle ground between whitelist (never clean) and the default (always clean on tab close). Greylisted domains keep cookies for the current browsing session, then auto-promote to whitelist on the next close OR get cleaned on the next close (configurable). Useful for one-off visits where you want session continuity but no long-term persistence. - q: Can I undo a cleanup if Guardian deletes something I needed? a: For cookies only — the Pro tier keeps 90 days of cookie history with one-click restore. For other storage types (localStorage, IndexedDB, Cache Storage), the cleanup is irreversible the moment Guardian runs it. The right protection for high-value state is the whitelist, not the history. --- # CookieVault Guardian > **TL;DR**: CookieVault Guardian is a free, MIT-licensed Manifest V3 extension that automatically deletes cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations when you close the last tab on a domain — except for whitelisted sites. Built as the modern replacement for Cookie AutoDelete after Chrome's MV2 sunset disabled the original in late 2024. CookieVault Guardian is a Manifest V3 browser extension that automatically cleans browser storage for a domain the moment its last tab closes. It is the modern, Manifest V3-native successor to Cookie AutoDelete[^1], the privacy extension Chrome disabled in late 2024 as the Manifest V2 sunset reached its final phase[^2]. Guardian rebuilds the per-tab cleanup workflow on the current Chrome extension APIs and extends the cleanup target list from "cookies only" to every browser-storage surface that can hold cross-session tracking state. ## What Guardian does > **In short**: Guardian listens for `chrome.tabs.onRemoved`, checks if any tab is still open on the closing tab's domain, and if not, deletes every storage API entry for that domain — unless the domain is whitelisted. Six storage targets, each individually toggleable. The whitelist supports per-domain rules, subdomain inheritance, and wildcard patterns. Six storage surfaces Guardian cleans: 1. **Cookies** — every cookie for the domain, including HttpOnly cookies the page itself cannot reach 2. **localStorage** — long-term key-value storage that survives across sessions and is invisible to cookie-only cleaners 3. **sessionStorage** — per-tab storage; cleaned defensively even though it normally clears with the tab 4. **IndexedDB** — structured per-origin database; often where trackers stash fingerprint state 5. **Cache Storage** — Service Worker cache API; can be used 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 in settings. Defaults are sensible — all six on except in cases where a critical site breaks (rare). A 2024 Mozilla blog on Total Cookie Protection[^3] frames the rationale: "Cookies are no longer the only mechanism for cross-site tracking, and a privacy tool that only cleans cookies misses the modern threat model." Guardian's six-surface scope is the operational response. ## The whitelist (the most important feature) > **In short**: The whitelist is the difference between Guardian being useful and Guardian being annoying. Add every site you want to stay logged in to; everything else cleans on tab close. Subdomain inheritance and wildcards make the whitelist short and stable. The whitelist UX is the modern reimplementation of Cookie AutoDelete's classic flow: - **Click the toolbar icon while on a site** → "Add to whitelist" — adds the current domain with subdomain inheritance on - **Wildcards** — `*.googleapis.com` whitelists every Google APIs subdomain - **Greylist** — a middle ground: "keep for this session, clean on next close" (or "auto-promote to whitelist on next visit") - **Containers (Firefox)** — per-container whitelist rules, matching Firefox's Multi-Account Containers extension A starter whitelist that covers most users in the first five minutes: - Your primary email (Gmail / Outlook / Proton) - Your code host (GitHub / GitLab) - Your work tools (Linear, Notion, Slack, Figma — whichever you use) - Your bank - Your password manager's web UI (1Password / Bitwarden) Everything else cleans on tab close by default. ## Browser support > **In short**: Every modern Chromium browser uses the Chrome Web Store build. Firefox uses a separate Manifest V3 build. Safari is not supported (Safari Web Extensions have a different cleanup model). | Browser | Source | Cookie AutoDelete also works? | | ------- | ---------------- | ------------------------------ | | Chrome | Chrome Web Store | No (Chrome MV2 sunset) | | Edge | Edge Add-ons | No (same Chromium policy) | | Brave | Chrome Web Store | No | | Opera | Chrome Web Store | No | | Vivaldi | Chrome Web Store | No | | Arc | Chrome Web Store | No | | Firefox | Firefox Add-ons | Yes (Firefox kept MV2 support) | | Safari | Not supported | N/A | If you only use Firefox and Cookie AutoDelete works for you, the urgent migration argument is weaker — Guardian's Firefox draw is the cross-browser whitelist sync, not "your current setup is broken." ## How Guardian compares | Feature | CookieVault Guardian | Cookie AutoDelete | | --------------------------- | -------------------- | ------------------------ | | Manifest version | V3 | V2 (deprecated) | | Chrome / Edge / Brave | Yes | No (disabled) | | Firefox | Yes | Yes | | Cleans cookies | Yes | Yes | | Cleans localStorage | Yes | Partial (later versions) | | Cleans IndexedDB | Yes | No | | Cleans Cache Storage | Yes | No | | Cleans Service Worker | Yes | No | | Whitelist / greylist | Yes | Yes | | Wildcard patterns | Yes | Yes | | Cross-device whitelist sync | Yes (Pro) | No | | Active maintenance | Yes | Slowed | Detailed page: [CookieVault Guardian vs Cookie AutoDelete](/en/vs/cookie-autodelete/). ## Pricing > **In short**: Free forever for local cleanup. $3.99/month or $29/year Pro for cross-device whitelist sync. Same pricing line as CookieVault Editor — they share an account when you have both. - **Free** — all cleanup, all storage types, up to 10 Guardian rules, greylist, wildcards. Permanent. - **Pro $3.99/mo or $29/yr** — E2E encrypted cross-device whitelist sync, 90-day cookie history with undo (cookies only). - **Team $9/seat/mo** — centralized rules across team members, audit log, SSO. Pro is only worth the money if you use Guardian on more than one device. ## How to install 1. **Verified manual release** — download the Guardian ZIP from the [download page](/en/download/?product=guardian) and follow the installation steps 2. **Edge Add-ons** — same Chromium build, Microsoft store 3. **Firefox Add-ons** — separate Manifest V3 build 4. **Direct CRX** for Opera / Vivaldi / Arc / Brave — GitHub release page, drag into extensions page 5. **Build from source** — clone the repo, `npm install && npm run build`, load unpacked After installing: 1. Pin the toolbar icon for one-click whitelist access 2. Visit each site you want to stay logged in to 3. Click the Guardian icon → "Add to whitelist" 4. Verify the whitelist in Settings → Whitelist 5. Browse normally — non-whitelisted tab closes trigger cleanup See the [auto-delete tab close how-to](/en/how-to/auto-delete-on-tab-close/) for the full setup walkthrough with edge cases. ## See also - [CookieVault Editor](/en/editor/) — the companion cookie editor (EditThisCookie successor) - [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/) — full migration guide with side-by-side feature matrix - [Auto-delete cookies on tab close](/en/how-to/auto-delete-on-tab-close/) — setup walkthrough - [Cookie whitelist](/en/features/cookie-whitelist/) — whitelist deep dive - [Pricing](/en/pricing/) — Free / Pro / Team breakdown - [Security](/en/security/) — E2E encryption design --- [^1]: The Cookie AutoDelete source code is at https://github.com/Cookie-AutoDelete/Cookie-AutoDelete under the MIT license. The Firefox Add-ons listing remains functional; the Chrome Web Store listing was disabled with the MV2 sunset. [^2]: Chrome's Manifest V2 deprecation timeline is documented at https://developer.chrome.com/docs/extensions/develop/migrate and the stable-channel disablement schedule at https://developer.chrome.com/blog/resuming-the-transition-to-mv3. [^3]: Mozilla's Total Cookie Protection announcement and technical writeup is at https://developer.mozilla.org/en-US/docs/Web/Privacy. The "cookies are no longer the only mechanism" framing is paraphrased from Mozilla's published privacy stance. ### pages/en/no-sale-pledge.md --- title: 'No-sale pledge — CookieVault will never sell your data' slug: no-sale-pledge description: 'CookieVault no-sale pledge draft — a permanent commitment never to sell, rent, or share user data, with the CCPA definition of "sale," permitted disclosures, and enforceability.' type: landing locale: en cluster: privacy author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-05-22 primaryKeyword: cookievault no data sale secondaryKeywords: - never sell user data pledge - privacy first cookie manager pledge - ccpa sale definition cookie extension - no data broker privacy commitment - cookie manager does not sell data intent: informational funnel: tofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What exactly is CookieVault pledging? a: That we will never sell, rent, lease, share for cross-context advertising, or otherwise monetize your data in exchange for value. This covers everyone — Free, Pro, and Team users — and every category of data we touch, including the email and billing identifiers we can read and the encrypted blobs we cannot. It is a permanent commitment, not a temporary marketing stance. - q: How does the pledge define "sale"? a: We use the broad CCPA definition — selling, renting, releasing, disclosing, or otherwise communicating personal information to a third party for monetary or other valuable consideration. That deliberately includes indirect arrangements like data licensing, lookalike-audience exports, programmatic ad bidding, and "anonymized" cohort sales, which is where many companies hide data monetization. - q: Does the pledge cover "sharing," not just selling? a: Yes. The CPRA added "sharing" for cross-context behavioral advertising precisely because some transfers are not technically sales. Our pledge covers both — we do not sell and we do not share for advertising. We run no advertising at all, so there is no business reason for either. - q: Are there any cases where you disclose my data? a: Only three narrow ones, and none is a sale. We disclose to Paddle to process your billing, to Cloudflare to host and transit your (encrypted) data, and to authorities when compelled by a valid court order or subpoena. We do not voluntarily hand data to anyone, and we never receive value for any disclosure. - q: What if CookieVault gets acquired? a: The pledge is written to bind any successor. A change-of-control clause in the terms of service carries the no-sale commitment to any acquirer, so a buyer cannot quietly switch on data sales after a purchase. This is the clause most "we value privacy" statements omit, and the one that actually matters. - q: How is a pledge like this enforceable? a: Several layers. Under the CCPA, a stated promise not to sell is enforceable by the California Privacy Protection Agency and Attorney General; misrepresenting it is also an unfair business practice. We additionally publish a PGP-signed statement archived in Git, fold the pledge into the binding terms of service, and bind acquirers via the change-of-control clause. - q: Why make this a separate page instead of burying it in the privacy policy? a: Because a pledge you have to dig for is a pledge designed to be missed. The data-broker economy depends on opacity; a plain, prominent, dated commitment is the opposite of that. Keeping it on its own page also makes it easy to cite, link, and hold us to. - q: Is this pledge legally final? a: The commitment is real and intended to be permanent, but this page is a pre-launch draft. The final PGP-signed statement, the transparency-report template, and the exact change-of-control wording will be finalized with counsel before launch. The promise itself — never sell, rent, or share — will not change. --- # No-sale pledge > **TL;DR**: CookieVault will never sell, rent, lease, share for cross-context advertising, or otherwise monetize your data. This is a permanent, enforceable commitment covering every user and every data category — not a temporary marketing line — and it binds any future acquirer. The no-sale pledge is CookieVault's permanent, public commitment never to sell, rent, lease, share for cross-context advertising, or otherwise monetize user data for value. It exists because the browser-extension and cookie-tooling space has a long history of products being acquired and quietly turned into data-collection vehicles — so a privacy-first product needs to say, plainly and durably, that it will not do that. ## Scope of the pledge > **In short**: The pledge covers every user (Free, Pro, Team) and every data category we touch — the email and billing IDs we can read, and the encrypted blobs we cannot. There are no carve-outs for "anonymized," "aggregated," or "de-identified" data. Everything the pledge covers: - **Cookie contents** — already end-to-end encrypted, and never sold or shared regardless - **Account email** — never sold, rented, or shared for advertising - **Billing identifiers** — the Paddle customer ID and related metadata - **Support correspondence** — never mined or monetized - **Aggregate analytics** — cookieless and aggregate-only, and never sold even in summary form - **Any "de-identified" derivative** — explicitly in scope, because de-identification is the usual loophole There is no asterisk for "anonymized" data, because re-identification of supposedly anonymous datasets is well documented and we will not lean on that fiction. ## What "sale" means > **In short**: We adopt the broad CCPA definition — any disclosure of personal data to a third party for monetary or other valuable consideration — and explicitly include the indirect arrangements (licensing, lookalike audiences, ad bidding, cohort sales) that companies use to monetize data without calling it a sale. | Practice | Counts as a "sale/share" under our pledge? | | --------------------------------- | ------------------------------------------ | | Selling data to a data broker | Yes — prohibited | | Licensing data for a fee | Yes — prohibited | | Lookalike-audience export to ads | Yes — prohibited | | Programmatic ad bidding with data | Yes — prohibited | | "Anonymized" cohort sale | Yes — prohibited | | Sharing for cross-context ads | Yes — prohibited | We use the CCPA's deliberately broad framing, which defines a "sale" to include releasing, disclosing, or otherwise communicating personal information for "monetary or other valuable consideration."[^1] The CPRA amendment separately added "sharing" for cross-context behavioral advertising, and our pledge covers that too.[^2] ## Permitted disclosures > **In short**: Exactly three, and none is a sale: Paddle for billing, Cloudflare for hosting and transit, and lawful compulsion by a valid court order. We never receive value for any of these, and we resist overbroad demands. The complete list of disclosures we do make: 1. **Paddle** — to process payments and tax as our Merchant of Record 2. **Cloudflare** — to host the service and transit your encrypted data 3. **Legal compulsion** — only under a valid subpoena or court order, and only the minimum required None of these is a sale: we receive no consideration, the recipients are service providers bound by contract or a court, and the encrypted blobs remain unreadable in transit and at rest. We commit to a transparency report summarizing any compelled disclosures. ## How this is enforceable > **In short**: A stated no-sale promise is enforceable under the CCPA by regulators, and misrepresenting it is an unfair business practice. We reinforce that with a PGP-signed statement in Git, integration into the binding terms of service, and a change-of-control clause that binds any acquirer. The enforceability stack, strongest legal layer first: - **Statutory** — under the CCPA/CPRA a no-sale representation is enforceable by the California Privacy Protection Agency and Attorney General, and misstating it is an unfair business practice[^1] - **Contractual** — the pledge is folded into the binding [terms of service](/en/terms/), making it part of your agreement with us - **Successor-binding** — a change-of-control clause carries the pledge to any acquirer, so a sale of the company cannot quietly enable a sale of your data - **Cryptographic provenance** — a PGP-signed copy of the pledge is archived in the public Git history, timestamped and tamper-evident ## See also - [Privacy policy](/en/privacy/) — what we collect and never collect - [Security](/en/security/) — the end-to-end encryption behind these promises - [Terms of service](/en/terms/) — where the pledge becomes contractually binding - [About](/en/about/) — why we are funded by subscriptions, not data --- [^1]: The CCPA's definition of "sale" and its enforcement are summarized by the California Attorney General: https://oag.ca.gov/privacy/ccpa. [^2]: The CPRA added the concept of "sharing" for cross-context behavioral advertising; for the consolidated California privacy code see the official legislative text portal: https://leginfo.legislature.ca.gov. ### pages/en/open-source.md --- title: 'Open source — CookieVault on GitHub (MIT, reproducible builds)' slug: open-source description: 'CookieVault Editor and Guardian are MIT-licensed browser extensions on GitHub. Read the client code, audit the cryptography, build it yourself, or contribute.' type: landing locale: en cluster: developer author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookievault open source secondaryKeywords: - cookievault github - open source cookie manager - mit licensed cookie extension - reproducible build extension - audit cookie extension intent: informational funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Is CookieVault really open source? a: Yes. The Editor and Guardian browser extensions are published in separate public GitHub repositories under the MIT license. Their shared client packages, including the cryptographic boundary that protects synced cookies, are included and auditable. The hosted sync service remains proprietary. - q: What license does CookieVault use? a: Both extension repositories use the MIT license. MIT is OSI-approved and permissive — you can read, fork, modify, and redistribute the extension code, subject to the license. CookieVault names and logos remain protected trademarks. - q: What are reproducible builds and why do they matter? a: A reproducible build means the binary published to the Chrome Web Store is byte-for-byte identical to what anyone gets by building the tagged Git commit. This lets you verify that the extension you install does exactly what the public source says — closing the "the source says X but the shipped binary does Y" gap that took down EditThisCookie. - q: How do I verify the store binary matches the source? a: Download the CRX from the store (or the GitHub release), compute its SHA-256, and compare it to the checksum published on the matching tagged release. If they match, the binary is the audited source. Full verification steps are in each repository's README. - q: Can I contribute to CookieVault? a: Yes. Read CONTRIBUTING.md, open a discussion before large changes, sign your commits, and use Conventional Commits. No CLA is required — we trust the MIT license. Good first issues are labeled in each repository. - q: Can I self-host the sync server? a: No. The hosted sync server is not part of the public extension repositories and is not offered as a self-hostable open-source component. The client-side encryption implementation is public, so you can verify that plaintext is encrypted before it leaves the browser. - q: Do you accept security audits of the code? a: Absolutely — independent audit is the point of publishing the code. We welcome audits of the cryptographic boundary and the cookie-handling logic, and an independent third-party audit of the crypto stack is planned for Q3 2026. Report findings to security@cookievault.net. --- # Open source > **TL;DR**: CookieVault Editor and Guardian are MIT-licensed open-source browser extensions. Each has its own public GitHub repository, including the shared client code and cryptography needed to build and audit it. The hosted sync service remains proprietary. CookieVault is open source at the extension layer: both browser extensions — Editor and Guardian — are published on GitHub under the MIT license, including the shared client packages and the on-device encryption code they need to build. Publishing that cryptographic boundary lets anyone verify that cookie plaintext is encrypted before it reaches the hosted sync service, which remains proprietary. ## What is published > **In short**: Both browser-extension clients and their required shared packages are public. The hosted sync service, internal documentation, and private operational material are not. | Repository | What it contains | License | | ---------------------------------------------------------------------------- | ------------------------------------------------------------ | ------- | | [CookieVault Editor](https://github.com/extensionsly/cookievault-editor) | Cookie manager extension and required shared client packages | MIT | | [CookieVault Guardian](https://github.com/extensionsly/cookievault-guardian) | Auto-delete extension and required shared client packages | MIT | The hosted sync service is deliberately kept outside these repositories. It stores ciphertext produced by the public client-side cryptographic implementation; the server does not need access to cookie plaintext. ## Why open source matters here > **In short**: A cookie extension has privileged access to your session tokens. Open source plus reproducible builds turns "trust us" into "verify us" — the only honest posture for a tool with that much access. Three reasons transparency is non-negotiable for this category: - **Privileged access** — an extension with the cookies permission can read every session token in your browser. You should be able to see exactly what it does with that access. - **The provenance gap** — EditThisCookie's source was visible, but the post-transfer store binary was not verifiable against it. Reproducible builds close that gap. - **Supply-chain resilience** — public code and signed, reproducible releases make a silent malicious update detectable rather than invisible. ## Reproducible builds > **In short**: Each Chrome Web Store release is tagged in Git, and the store binary is byte-identical to the CI artifact for that tag. Verify with a SHA-256 comparison. The verification flow is four steps: 1. Note the version of the extension you have installed (or want to verify) 2. Find the matching tagged release on GitHub and download its `SHA256SUMS` 3. Download the CRX (from the store or the release) and run `sha256sum` on it 4. Compare the two checksums — a match proves the binary is the published source This procedure means you never have to take our word for what the extension does; the math does the trusting. ## How to contribute > **In short**: Read CONTRIBUTING.md, discuss before large PRs, sign commits, use Conventional Commits. No CLA required. - **Read `CONTRIBUTING.md`** in the relevant repository first - **Open a discussion** before large or architectural changes - **Sign your commits** so authorship is verifiable - **Use Conventional Commits** (`feat:`, `fix:`, `docs:`, etc.) - **No CLA** — we trust the MIT license and do not require contributor agreements - **Good first issues** are labeled in each repository ## License The Editor and Guardian repositories use the MIT license. You may read, fork, modify, build, and redistribute their code under those terms. The CookieVault name and logos are not granted under the MIT license and remain protected trademarks. ## See also - [Security](/en/security/) — the encryption design you can audit - [About](/en/about/) — who maintains the code and how it is funded - [Download](/en/download/) — install from a store or build from source - [No-sale pledge](/en/no-sale-pledge/) — the data commitment behind the code - [Encrypted cloud sync](/en/features/encrypted-cloud-sync/) — the crypto boundary in detail ### pages/en/pricing.md --- title: 'Pricing — CookieVault' slug: pricing description: 'CookieVault pricing — Free for local cookie control. Pro from $3.99/month adds encrypted sync, unlimited profiles and rules, 90-day history, and CSV/HAR export. 30-day refund.' type: landing locale: en cluster: tool author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookievault pricing secondaryKeywords: - cookie manager price - cookie extension free - cookie sync subscription intent: commercial funnel: bofu schemaType: - SoftwareApplication - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Is CookieVault really free? a: Yes. Free includes unlimited cookie CRUD and search, JSON import/export, auto-delete across supported storage types, 1 local profile, and up to 10 Guardian rules. No card or time limit is required. - q: What does Pro add over Free? a: Pro adds unlimited profiles and Guardian rules, one-click profile switching, end-to-end encrypted cross-device sync, 90-day cookie history with undo, CSV/HAR export, and email support. Profile and rule sharing are Team features. - q: What payment methods are accepted? a: CookieVault uses Paddle as its Merchant of Record. Paddle accepts Visa, Mastercard, American Express, PayPal, Apple Pay, and Google Pay. Paddle handles VAT, sales tax, and invoicing in 100+ jurisdictions automatically. - q: Can I cancel anytime? a: Yes. Cancel from the billing portal at any time. Your Pro access continues until the end of the current billing period (month or year), then reverts to Free. No cancellation penalty. - q: Is there a refund policy? a: Yes — 30-day, no-questions-asked refund on any Pro or Team purchase. Email support@cookievault.net or request through the Paddle billing portal. - q: Do I need Pro for both Editor and Guardian? a: One Pro subscription covers both extensions. If you have Pro, both Editor sync and Guardian whitelist sync are active. The same account, the same passphrase, the same billing line. - q: What is the Team tier for? a: Team ($8/seat/month) is for QA teams and development consultancies that need centralized billing, an audit log of cookie operations, SCIM provisioning, SSO, and the ability to share cookie inventories and whitelist rules across team members. - q: Will the price go up? a: Current pricing ($3.99/month Pro, $8/seat/month Team) is locked for all subscribers who sign up before the first public price change. If we adjust pricing, existing subscribers keep their original rate. New price changes will be announced at least 30 days in advance and posted here. --- # Pricing > **TL;DR**: CookieVault is free forever for local cookie control. Pro is $3.99/month, $29/year, or $59 lifetime and adds unlimited profiles and rules, one-click switching, encrypted sync, 90-day history, and CSV/HAR export. Team is $8/seat/month and is currently coming soon. CookieVault pricing is a simple two-tier model designed around one principle: the features you need to replace EditThisCookie and Cookie AutoDelete are free, permanently, without a paywall. The Pro tier exists for a single reason — encrypted cross-device sync — and is priced at the low end of comparable privacy-tool subscriptions. ## Free tier — what you get > **In short**: Everything you need to replace EditThisCookie (Editor) and Cookie AutoDelete (Guardian) in a single Free install, forever, without a card. Most users never need Pro. Six capabilities in the Free tier that cover the full EditThisCookie + Cookie AutoDelete replacement workflow: 1. **Full cookie CRUD** — view, create, edit, delete with SameSite / HttpOnly / Secure / Expires attribute editing 2. **Export** — JSON import and export 3. **Multi-account profiles** — 1 named local profile 4. **Auto-delete on tab close** — cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, Service Worker registrations 5. **Guardian rules** — up to 10 local whitelist, greylist, or wildcard rules 6. **Dark mode** — system-aware, with manual override ## Pro tier — when you need it > **In short**: You need Pro if (and only if) you use more than one device and want your cookies / whitelist synced between them, or you want the safety net of cookie-history undo. $3.99/month, $29/year (39% off), or $59 lifetime. Covers both Editor and Guardian. Three scenarios where Pro pays for itself: - **Multi-device developer** — laptop at work, desktop at home, both need the same cookie profiles and whitelist rules. Pro syncs them automatically. - **QA engineer with test fixtures** — export cookies on one machine, import on another via sync, without emailing JSON files around. - **Accidental tab-close insurance** — Pro's 90-day cookie history lets you restore individual cookies you closed by accident, one click at a time. ## Billing and refunds > **In short**: Paid through Paddle (Merchant of Record). 30-day no-questions-asked refund. Cancel anytime, access continues to end of billing period. Six billing facts: - **Payment processor**: Paddle — handles VAT, sales tax, and invoicing in 100+ jurisdictions automatically - **Payment methods**: Visa, Mastercard, American Express, PayPal, Apple Pay, Google Pay - **Refund**: 30 days, no questions asked - **Cancel**: anytime; access continues until end of billing period, then reverts to Free - **Invoices**: automatic, downloadable from the Paddle billing portal - **Price lock**: subscribers who sign up before any future price change keep their original rate ## See also - [CookieVault Editor](/en/editor/) — the cookie manager extension - [CookieVault Guardian](/en/guardian/) — the auto-delete extension - [Security](/en/security/) — how the E2E encrypted sync works - [Download](/en/download/) — store links for all seven browsers - [EditThisCookie alternative](/en/alternatives/editthiscookie/) — why the Free tier covers the full migration - [Cookie AutoDelete alternative](/en/alternatives/cookie-autodelete/) — why Guardian's Free tier is the successor ### pages/en/privacy.md --- title: 'Privacy policy — CookieVault' slug: privacy description: 'CookieVault privacy policy draft — what we collect (email, opaque ciphertext, billing ID), what we never collect, GDPR/CCPA/LGPD rights, retention, and subprocessors.' type: landing locale: en cluster: privacy author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookievault privacy policy secondaryKeywords: - privacy first cookie manager - end to end encrypted cookie sync privacy - gdpr ccpa cookie extension - cookie manager no tracking - zero knowledge sync privacy intent: informational funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What personal data does CookieVault collect? a: For Pro and Team accounts we collect three things — your email address (for login and receipts), an opaque encrypted sync blob we cannot decrypt, and a Paddle customer ID for billing. Free local-only users create no account and we collect nothing about them. We never collect the contents of your cookies, your browsing history, your IP address, or behavioral telemetry. - q: Can CookieVault read the cookies I sync? a: No. Cookies are encrypted on your device with a key derived from your passphrase via PBKDF2-SHA-256 before they ever leave the browser, then encrypted again per record with AES-256-GCM (Web Crypto API). The sync server stores only ciphertext. Neither CookieVault staff nor a full server compromise can decrypt your cookies. This is what "zero-knowledge" means in practice. See the [security page](/en/security/) for the threat model. - q: Do you use Google Analytics or any cookie-based tracker? a: No. The website uses Cloudflare Web Analytics and Plausible, both of which are cookieless and aggregate-only — they set no tracking cookies and build no per-visitor profile. The browser extension ships with zero third-party analytics SDKs. There is no Google Analytics, no Meta Pixel, no Hotjar, and no fingerprinting anywhere in our stack. - q: Who are your subprocessors? a: Two. Cloudflare hosts the website and the sync API and stores the encrypted blobs. Paddle is our Merchant of Record and processes payments and tax across 100+ jurisdictions. We use no advertising networks, no data brokers, and no analytics processors that receive personal data. The current list is published in the subprocessors table on this page. - q: How do I exercise my GDPR, CCPA, or LGPD rights? a: Email privacy@cookievault.net from the address on your account. You can request access, a portable export, correction, or deletion, and you can object to or restrict processing. We aim to respond within 30 days. Because most of your data is ciphertext we cannot read, deletion is usually immediate and verifiable. - q: How long do you keep my data? a: Account data (email, settings) is kept until you delete your account, plus a 30-day grace window for accidental-deletion recovery, after which it is purged. Encrypted sync blobs persist until you delete them from the client. Billing records held by Paddle are retained as long as tax and accounting law require, typically up to seven years. - q: What happens to my data if I cancel or delete my account? a: Cancelling stops billing and disables sync but leaves your local cookies untouched in the browser. Deleting your account triggers a purge of your email and encrypted blobs after the 30-day grace window. Paddle retains the minimum invoice records that tax law requires; everything else is erased. - q: Is this privacy policy legally final? a: Not yet. This page is an honest draft published for transparency while the product is in pre-launch. The legally binding version, the Data Processing Addendum, and the GDPR Article 30 record of processing will be finalized with counsel before public launch. The substance — what we collect and never collect — is not expected to change. --- # Privacy policy > **TL;DR**: CookieVault's privacy policy is short because we collect almost nothing — an email, an opaque encrypted sync blob we cannot read, and a billing ID. We never see your cookies, your browsing history, your IP, or any telemetry, and we never sell data. A privacy policy is the document that tells you exactly what data a service collects about you, why, how long it keeps it, who it shares it with, and what rights you have over it. CookieVault's policy is unusually short because the product is built so that we hold as little of your data as technically possible: cookie contents are end-to-end encrypted on your device before they reach us, so the server only ever stores ciphertext it cannot decrypt.[^1] ## What we collect > **In short**: For paid accounts: your email, an opaque encrypted sync blob, and a Paddle customer ID. For Free local-only users: nothing, because there is no account. Article 5(1)(c) of the GDPR calls this data minimisation — "adequate, relevant and limited to what is necessary"[^2] — and it is the design rule the whole product follows. | Data we collect | Purpose | Who has it | Can we read it? | | --------------------- | ---------------------------------- | ----------- | ------------------------- | | Email address | Login, receipts, security notices | CookieVault | Yes | | Opaque sync blob | Cross-device encrypted cookie sync | CookieVault | No — ciphertext only | | Paddle customer ID | Billing and tax processing | CookieVault | Yes (an opaque ID) | | Payment card details | Charging your subscription | Paddle only | No — we never receive it | | Support email content | Answering your support request | CookieVault | Yes, until ticket closure | Free users who never create an account generate none of the above. The extension stores your cookies and profiles locally and makes no network calls unless you explicitly enable sync on a paid plan. ## What we never collect > **In short**: We never collect the contents of your cookies, your browsing history, your IP address, or behavioral telemetry. The GDPR principle is that the lawful basis for processing must be specific — and we simply have no basis, and no desire, to gather any of this.[^2] The list of things CookieVault deliberately does not collect: 1. **Cookie contents** — encrypted on-device before sync; we store only ciphertext 2. **Browsing history** — the extension never reads or transmits the pages you visit 3. **IP addresses** — our analytics are cookieless and aggregate-only, with no per-visitor IP logging 4. **Device fingerprints** — no canvas, no WebGL, no font enumeration 5. **Behavioral telemetry** — the extension ships with zero analytics SDKs 6. **Third-party ad identifiers** — we run no advertising and integrate no ad networks Our website analytics are Cloudflare Web Analytics and Plausible, both cookieless and aggregate-only by design, which is why this site shows no cookie-consent banner — there is nothing to consent to. ## Your rights > **In short**: Under the GDPR, CCPA, and LGPD you have rights of access, deletion, correction, portability, and objection. Email privacy@cookievault.net and we respond within 30 days. Because most of what we hold is ciphertext we cannot read, deletion is fast and verifiable. The rights you can exercise, by framework: - **GDPR (EU/EEA/UK)** — access, rectification, erasure, restriction, portability, and objection under Articles 15–22[^3] - **CCPA/CPRA (California)** — know, delete, correct, and opt out of "sale" or "sharing" under Cal. Civ. Code §1798.100 et seq.[^4] - **LGPD (Brazil)** — confirmation, access, correction, anonymisation, portability, and deletion under Lei 13.709/2018[^5] To exercise any right, email `privacy@cookievault.net` from your account address. We do not charge a fee for reasonable requests and aim to respond within 30 days. ## Retention > **In short**: Account data is kept until you delete your account, plus a 30-day grace window, then purged. Encrypted blobs live until you delete them client-side. Billing records are kept as long as tax law requires (commonly up to seven years), and only by Paddle. | Data type | Retention period | Trigger to delete | | ----------------------- | ---------------------------------------------- | -------------------------- | | Account email | Until account deletion + 30-day grace | You delete your account | | Encrypted sync blob | Until you delete it from the client | Client-side delete | | Support correspondence | Until ticket closure + 12 months | Automatic purge | | Billing/invoice records | As required by tax law, commonly up to 7 years | Statutory minimum (Paddle) | ## Subprocessors > **In short**: Exactly two — Cloudflare for hosting and sync transit, and Paddle as our Merchant of Record for billing. No analytics processors receive personal data, and we use no advertising networks or data brokers. A current list is maintained here. | Subprocessor | Role | Data they handle | Location | | ------------ | ------------------------------------ | -------------------------------------- | ----------- | | Cloudflare | Hosting, sync API, encrypted storage | Opaque ciphertext, request metadata | Global edge | | Paddle | Merchant of Record, billing, tax | Name, email, payment details, invoices | Global | Cloudflare only ever sees encrypted blobs and routine request metadata; it never holds keys.[^6] Paddle, as Merchant of Record, handles payment data and VAT/sales-tax compliance across 100+ jurisdictions, which is why your card details reach Paddle and never us.[^7] If we ever add or change a subprocessor, we will update this table and notify Pro subscribers in advance. ## See also - [Security](/en/security/) — the encryption architecture that makes this policy possible - [No-sale pledge](/en/no-sale-pledge/) — our permanent commitment never to sell data - [Terms of service](/en/terms/) — the agreement that governs your use of the service - [About](/en/about/) — who builds CookieVault and how it is funded --- [^1]: "End-to-end encryption" means data is encrypted on the sender's device and decrypted only on the recipient's, so intermediaries store ciphertext they cannot read. For background see Mozilla's privacy documentation: https://developer.mozilla.org/en-US/docs/Web/Privacy. [^2]: GDPR Article 5(1) sets out the data-minimisation and purpose-limitation principles. Official consolidated text: https://gdpr-info.eu/art-5-gdpr/. [^3]: GDPR data-subject rights are defined in Articles 15–22. See the UK Information Commissioner's Office guidance: https://ico.org.uk. [^4]: The California Consumer Privacy Act, as amended by the CPRA, is summarized by the California Attorney General: https://oag.ca.gov/privacy/ccpa. [^5]: Brazil's Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) is administered by the ANPD: https://www.gov.br/anpd/pt-br. [^6]: Cloudflare's own privacy commitments are published here: https://www.cloudflare.com/privacypolicy/. [^7]: Paddle acts as Merchant of Record, taking on tax and payment compliance. Privacy details: https://www.paddle.com/legal/privacy. ### pages/en/security.md --- title: 'Security at CookieVault — Architecture, audits, disclosure' slug: security description: 'CookieVault security draft — PBKDF2-SHA-256 key derivation, AES-256-GCM zero-knowledge sync, open-source auditable code, responsible disclosure, bug bounty, and audit plan.' type: landing locale: en cluster: privacy author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookievault security secondaryKeywords: - end to end encrypted cookie sync - zero knowledge cookie manager - pbkdf2 sha-256 aes-256-gcm encryption - responsible disclosure cookie extension - open source cookie manager security intent: informational funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: How does CookieVault encrypt my cookies? a: Your passphrase is processed on-device with PBKDF2-SHA-256 (600,000 iterations) to derive an encryption key. Each cookie record is then encrypted with AES-256-GCM through the browser Web Crypto API using a fresh 96-bit IV. Only authenticated ciphertext leaves your browser; the sync server never holds your passphrase or derived key. - q: What does "zero-knowledge" mean here? a: It means the server has zero knowledge of your plaintext. Because keys are derived on-device from a passphrase we never receive, neither CookieVault staff, a malicious insider, nor an attacker who fully compromises the server can decrypt your cookies. The strongest claim a database breach could make is "we leaked ciphertext nobody can read." - q: Can I verify the security claims myself? a: Yes. The Editor and Guardian browser extensions are MIT-licensed and public on GitHub; the hosted sync service remains proprietary. The cryptographic boundary — where plaintext becomes ciphertext — runs inside the extensions, so it is in code you can read. Chrome Web Store releases are tagged in Git and reproducible-built, so you can match the published binary's SHA-256 to the tagged commit's CI artifact. - q: How do I report a security vulnerability? a: Email security@cookievault.net, optionally encrypting with the PGP key published at /.well-known/pgp-key.txt. We follow a 90-day coordinated-disclosure window, accelerated for actively exploited issues, and publish a security advisory for every fix. A machine-readable contact is also served at /.well-known/security.txt. - q: Is there a bug bounty? a: A paid bug-bounty program launches once CookieVault reaches 10,000 installs, which is when a budget can responsibly sustain payouts. Until then we credit researchers in release notes and on a public security hall-of-fame page, and we always acknowledge good-faith reports. - q: When will CookieVault get an independent audit? a: An independent third-party security audit of the cryptographic design and implementation is planned for Q3 2026. We will publish the audit report, the scope, and our remediation of any findings. Until then the open-source code and reproducible builds are the primary basis for independent verification. - q: What happens if I forget my passphrase? a: Because we never receive your passphrase or derived key, we cannot reset it or recover your synced data — that is the direct trade-off of zero-knowledge design. We provide an optional recovery key at setup that you store yourself. Your local cookies in the browser are unaffected; only the encrypted sync history depends on the passphrase. - q: Are these security details final? a: The architecture is stable, but this page is a pre-launch draft. The full threat-model document, the PGP key fingerprint, and the audit table of contents will be published before launch. The encryption primitives described here — PBKDF2-SHA-256 and AES-256-GCM — are the intended production design. --- # Security > **TL;DR**: CookieVault encrypts cookies on your device with PBKDF2-SHA-256-derived keys and AES-256-GCM before they ever reach our servers, so sync is zero-knowledge — we store ciphertext we cannot read. The code is open-source and auditable, with responsible disclosure, a bug bounty after 10,000 installs, and an independent audit planned for Q3 2026. Security at CookieVault is the practice of ensuring that the data you trust to the product — chiefly the cookies you sync between devices — cannot be read by anyone but you, including us. The product achieves this with end-to-end encryption: keys are derived on your device from a passphrase we never receive, cookies are sealed before they leave the browser, and the cloud stores only opaque ciphertext. ## Encryption architecture > **In short**: Your passphrase is processed on-device with PBKDF2-SHA-256 (600,000 iterations), and each cookie record is authenticated and encrypted with AES-256-GCM through the browser Web Crypto API. A per-device key enables fast unlock, so the passphrase is only needed when enrolling a new device. | Layer | Primitive | Role | | ----------------- | --------------------- | ----------------------------------------------- | | Key derivation | PBKDF2-SHA-256 | Stretch passphrase into a strong key, on-device | | Record encryption | AES-256-GCM | Authenticated encryption of each cookie record | | Library | Web Crypto API | Audited, widely deployed crypto implementation | | Fast unlock | Per-device device key | Avoids re-entering the passphrase every session | PBKDF2-SHA-256 is a standards-based password key-derivation function; CookieVault configures it for 600,000 iterations to raise the cost of offline guessing.[^1] AES-256-GCM provides authenticated encryption and uses a fresh 96-bit IV for each record through the browser-native Web Crypto API.[^2][^3] ## Open source and auditability > **In short**: The Editor and Guardian browser extensions are MIT-licensed and public; the hosted sync service is proprietary. The cryptographic boundary runs inside the extensions, so it is in code you can read, and store releases are reproducible-built from tagged Git commits so you can verify the binary matches the source. How you can independently verify the claims: 1. **Read the source** — the Editor and Guardian extensions, including the in-browser sync client, are public on GitHub under the MIT license (the hosted sync server is proprietary) 2. **Locate the crypto boundary** — find where plaintext cookies become ciphertext before any network call 3. **Check the tagged release** — every Chrome Web Store version maps to a Git tag 4. **Reproduce the build** — run the documented build to regenerate the artifact 5. **Compare hashes** — match the store binary's SHA-256 against the tagged CI artifact This is what "auditable" means in practice: not a promise that the code is secure, but the ability for anyone to check it. Reproducible builds close the gap between "the source looks safe" and "the binary I installed is that source." ## Vulnerability disclosure > **In short**: Email security@cookievault.net, optionally PGP-encrypted using the key at /.well-known/pgp-key.txt. We run a 90-day coordinated-disclosure window, accelerate for active exploitation, and publish an advisory for every fix. Our disclosure commitments: - **Contact** — `security@cookievault.net`, with a machine-readable pointer at `/.well-known/security.txt` - **Encryption** — PGP public key published at `/.well-known/pgp-key.txt` (fingerprint added before launch) - **Timeline** — 90-day standard coordinated-disclosure window, accelerated for actively exploited issues - **Transparency** — a public security advisory accompanies every fix - **Credit** — researchers are credited unless they prefer to remain anonymous A 90-day window aligns with the de-facto industry norm popularized by Google's Project Zero, which balances giving vendors time to fix against leaving users exposed.[^4] ## Bug bounty and audits > **In short**: A paid bug-bounty program starts at 10,000 installs, when payouts are sustainable; until then researchers get public credit. An independent third-party security audit is planned for Q3 2026, and we will publish its report and our remediation. | Program | Status | Milestone | | ----------------- | ------------------ | ------------------------------- | | Hall of fame | Active from launch | Public credit for valid reports | | Paid bug bounty | Planned | Launches at 10,000 installs | | Independent audit | Planned | Q3 2026, report published | Sequencing the paid bounty after 10,000 installs is a deliberate, honest constraint: a credible bounty needs a budget that can pay out reliably, and we would rather credit researchers transparently now than advertise a bounty we cannot yet fund. ## See also - [Privacy policy](/en/privacy/) — what we collect and never collect - [No-sale pledge](/en/no-sale-pledge/) — our commitment never to sell data - [Open source](/en/open-source/) — MIT license, reproducible builds, contribution guide - [Editor](/en/editor/) — the extension whose sync this architecture protects --- [^1]: PBKDF2 is specified in PKCS #5 / RFC 8018: https://datatracker.ietf.org/doc/html/rfc8018. [^2]: AES-GCM is specified in NIST SP 800-38D: https://csrc.nist.gov/pubs/sp/800/38/d/final. [^3]: The browser-native Web Crypto API provides the PBKDF2 and AES-GCM implementations used here: https://www.w3.org/TR/WebCryptoAPI/. [^4]: The 90-day coordinated-disclosure norm is documented by Google's Project Zero: https://googleprojectzero.blogspot.com. ### pages/en/terms.md --- title: 'Terms of service — CookieVault' slug: terms description: 'CookieVault terms of service draft — your rights, prohibited uses, liability cap (12 months of fees or US$50), 30-day change notice, and how the MIT license governs the code.' type: landing locale: en cluster: privacy author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookievault terms of service secondaryKeywords: - cookievault terms and conditions - cookie manager acceptable use policy - cookievault liability limitation - cookievault mit license terms - cookievault refund policy intent: informational funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: What do these terms actually govern? a: These terms govern your use of the CookieVault hosted service — the website, accounts, and the Pro and Team sync features. They do not restrict the open-source code, which is licensed separately under the permissive MIT license. In short, the terms cover the service we run for you; the MIT license covers the code you can run yourself. - q: Can I use CookieVault for commercial work? a: Yes. You may use CookieVault on unlimited personal and work devices, run it for commercial development and QA, and fork the MIT-licensed Editor and Guardian extension code. The hosted sync service is proprietary and not self-hostable. The Team plan adds centralized billing, an audit log, SSO, and SCIM provisioning for organizations that need it. - q: What am I not allowed to do? a: You may not use CookieVault to phish, impersonate, or commit fraud, to access systems or accounts you are not authorized to access, to violate a website's terms in a way that breaks the law, or to resell our hosted Pro or Team service as if it were your own. You also may not attempt to attack, overload, or reverse the encryption of the sync infrastructure. - q: What is the limit on CookieVault's liability? a: To the extent the law allows, our total liability for any claim is capped at the greater of the fees you paid us in the 12 months before the claim, or US$50. The service is provided "as is" without warranties. This is a standard limitation that keeps a small independent project sustainable; it does not waive rights that consumer-protection law makes non-waivable in your jurisdiction. - q: How will I be told about changes to these terms? a: We post material changes at least 30 days before they take effect and email Pro and Team subscribers directly. Continuing to use the service after the effective date is how you accept the new terms. If you disagree, you can cancel before the date and export your data. - q: Do I get a refund if I cancel? a: Yes — we offer a 30-day money-back guarantee on first Pro and Team purchases. Email billing within 30 days of the charge and Paddle, our Merchant of Record, processes the refund. After 30 days, cancelling stops future renewals but does not refund the current period. - q: How does the MIT license relate to these terms? a: The MIT license is the most permissive mainstream open-source license — it lets anyone use, modify, and redistribute the code with almost no restriction beyond keeping the copyright notice. It governs the Editor and Guardian extension code. These terms govern the hosted service we operate, including the proprietary sync server, which is not covered by the MIT license. - q: Are these terms legally final? a: No. This is an honest draft published during pre-launch for transparency. The binding version, including the governing-law clause and dispute-resolution mechanism, will be finalized with counsel and aligned with GDPR, CCPA, and consumer-protection requirements before public launch. --- # Terms of service > **TL;DR**: Use CookieVault for any lawful purpose on unlimited devices. Don't phish, impersonate, attack the service, or resell our hosted plan as your own. The service is provided as-is, our liability is capped at 12 months of fees or US$50, and the open-source code is governed separately by the MIT license. Terms of service are the contract that sets out the rules for using a hosted product — your rights, the limits on those rights, and how disputes are handled. CookieVault's terms govern the hosted service (the website, accounts, and Pro/Team sync), while the Editor and Guardian extension code is governed separately and more permissively by the MIT license, so anyone forking that extension code gets broader freedoms than the hosted-service rules alone would imply. ## Your rights > **In short**: Use CookieVault broadly and freely — unlimited devices, commercial use, and forking the Editor and Guardian extension code under MIT. The hosted service adds convenience (sync, history, team features); the open-source extension code gives you independence. What you are explicitly permitted to do: 1. Install and use the extension on unlimited personal and work devices 2. Use CookieVault for commercial development, QA, and privacy work 3. Enable end-to-end encrypted sync on a Pro or Team plan 4. Fork, modify, and redistribute the Editor and Guardian extension code under the MIT license 5. Export your data at any time in an open format 6. Cancel at any time, with a 30-day money-back guarantee on first purchase ## What you may not do > **In short**: No phishing, impersonation, fraud, unauthorized access, or attacks on the infrastructure, and no reselling our hosted service as your own. Acceptable-use limits like these are standard; cookie tooling is dual-use, and these rules draw the line at illegal or abusive use. | Prohibited use | Why it is prohibited | | ------------------------------------- | ---------------------------------------------------------------------------------- | | Phishing, impersonation, or fraud | Illegal and harms users | | Accessing accounts you don't own | Unauthorized access is unlawful in most jurisdictions | | Circumventing paywalls unlawfully | May breach the publisher's terms and applicable law | | Attacking or overloading the sync API | Threatens availability for everyone | | Reselling our hosted Pro/Team service | The MIT extension code is yours to fork; our hosted service is not yours to resell | Cookies are dual-use infrastructure: the same export feature that helps a QA engineer capture a test fixture could, in the wrong hands, move a stolen session. These rules exist to keep the lawful, legitimate uses open while drawing a clear line at abuse. ## Liability > **In short**: The service is provided "as is." Our total liability for any claim is capped at the greater of the fees you paid in the prior 12 months or US$50. Liability caps like this are normal for software services and keep a small independent team viable, without waiving non-waivable consumer rights. The limitation, stated plainly: - The service is provided **as is** and **as available**, without express or implied warranties - Our aggregate liability is capped at the **greater of (a) fees you paid in the prior 12 months or (b) US$50** - We are not liable for indirect, incidental, or consequential damages to the extent the law permits - Nothing here removes rights that consumer-protection law makes **non-waivable** in your jurisdiction ## Changes > **In short**: We give at least 30 days' notice of material changes and email subscribers. Using the service after the effective date means you accept the new terms; if you disagree, cancel and export before then. How changes work: 1. We draft the change and set an effective date at least 30 days out 2. We post the updated terms with a visible change summary and a new `lastUpdated` date 3. We email Pro and Team subscribers directly 4. You may accept by continuing to use the service, or decline by cancelling and exporting before the effective date ## Governing law and disputes > **In short**: The governing-law and arbitration details are being finalized with counsel and shown here as placeholders. Small-claims actions and intellectual-property claims are excluded from any arbitration requirement. Governing law and venue will be specified in the counsel-reviewed version. Disputes will be resolved by binding arbitration, except that either party may bring an individual action in small-claims court, and either party may seek injunctive relief for intellectual-property claims. The MIT license, which carries its own disclaimer of warranty, governs any dispute about the open-source code itself.[^1] ## See also - [Privacy policy](/en/privacy/) — what we collect and your data rights - [Security](/en/security/) — how sync data is encrypted end-to-end - [No-sale pledge](/en/no-sale-pledge/) — our binding commitment never to sell data - [Pricing](/en/pricing/) — Free, Pro, and Team plans and the refund window --- [^1]: The MIT license text and its warranty disclaimer are published by the Open Source Initiative: https://opensource.org/license/mit. ### vs/en/cookie-autodelete.md --- title: 'CookieVault Guardian vs Cookie AutoDelete — Successor comparison' slug: cookie-autodelete description: 'CookieVault Guardian vs Cookie AutoDelete compared: Manifest V3 vs V2, available vs disabled in Chrome, expanded storage cleanup vs cookies-only. Honest successor comparison.' type: vs locale: en cluster: migration author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookievault vs cookie autodelete secondaryKeywords: - cookie autodelete comparison - cookie autodelete vs cookievault guardian - cookie autodelete successor - cookie autodelete disabled chrome - auto delete cookies extension comparison - cookie autodelete firefox alternative intent: commercial funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Does Cookie AutoDelete still work in 2026? a: It depends on the browser. On Firefox, which kept Manifest V2 support, the maintained Cookie AutoDelete build still installs and runs. On Chrome and other Chromium browsers it is disabled, because Chrome's Manifest V2 sunset force-disabled all MV2 extensions in the stable channel between mid-2024 and early 2025, and Cookie AutoDelete was never rewritten for Manifest V3. - q: Is CookieVault Guardian a replacement for Cookie AutoDelete? a: Yes. Guardian rebuilds Cookie AutoDelete's tab-close auto-cleanup workflow on Manifest V3, with whitelist and greylist parity, wildcard matching, and Firefox container support. It also imports Cookie AutoDelete's JSON whitelist export, so you do not have to rebuild your domain list by hand. - q: What does Guardian clean that Cookie AutoDelete did not? a: Cookie AutoDelete cleaned cookies and, in later versions, partial localStorage. Guardian extends the same per-domain, tab-close model to cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations — every browser-storage surface that can hold cross-session tracking state. Each storage type is individually toggleable. - q: Should I migrate from Cookie AutoDelete if I only use Firefox? a: There is no urgency. Cookie AutoDelete on Firefox still works and is not going away tomorrow. Guardian on Firefox mainly helps two groups — users who want broader storage cleanup than cookies-only, and users who want one synced whitelist shared across Firefox and Chromium browsers. If neither applies to you, staying on Cookie AutoDelete is reasonable. - q: Are both Cookie AutoDelete and Guardian open source? a: Yes. Cookie AutoDelete is MIT-licensed and its source remains on GitHub. CookieVault Guardian is also MIT-licensed, and additionally ships reproducible Chrome Web Store builds so the published binary can be verified against a tagged commit. License is not a differentiator here; manifest version and storage scope are. - q: Can Guardian import my Cookie AutoDelete whitelist? a: Yes. Export your whitelist and greylist from Cookie AutoDelete as JSON, then in Guardian choose Settings → Import → Cookie AutoDelete JSON. The importer parses whitelist, greylist, expression matching mode (wildcard, regex, or domain), and per-container associations on Firefox, then rehydrates them into Guardian's rule store. - q: Is Cookie AutoDelete lighter than Guardian? a: Yes, somewhat. Cookie AutoDelete packs to roughly 150 KB, while Guardian packs to roughly 480 KB because it bundles the sync client and a crypto library. If install size is a priority and you do not need expanded storage cleanup or sync, that is a genuine point in Cookie AutoDelete's favor on Firefox. - q: Can Guardian's cleanup be undone if I close a tab by accident? a: Cookie and storage cleanup is irreversible the moment it runs — once data leaves the browser's storage, the browser cannot recover it, which is true of Cookie AutoDelete as well. The protection is to whitelist high-value sites. Guardian's Pro tier additionally keeps a 90-day cookie history (cookies only, not other storage types) so individual cookies can be restored after an accidental close. - q: Is Guardian the same as CookieVault Editor? a: No. They are two separate extensions. Editor is the EditThisCookie-style cookie manager for viewing and editing individual cookies. Guardian is the Cookie AutoDelete-style tab-close cleaner. You can install either or both; this page compares Guardian, the cleanup tool, against Cookie AutoDelete. --- # CookieVault Guardian vs Cookie AutoDelete > **TL;DR**: Cookie AutoDelete was the privacy community's tab-close cookie cleaner, but Chrome's Manifest V2 sunset disabled it on Chromium browsers in late 2024. CookieVault Guardian is the Manifest V3 successor — same whitelist workflow, expanded to localStorage, IndexedDB, Cache Storage, and more. Cookie AutoDelete still works on Firefox. CookieVault Guardian vs Cookie AutoDelete is a comparison between a Manifest V3 tab-close storage cleaner and the Manifest V2 cleaner it succeeds on Chromium. CookieVault Guardian is a free, MIT-licensed extension that rebuilds Cookie AutoDelete's per-domain auto-cleanup workflow on modern extension APIs and extends it from cookies-only to every browser-storage surface, while Cookie AutoDelete is the long-running open-source cleaner that Chrome disabled in its Manifest V2 sunset but that remains functional on Firefox. This page compares the two honestly, including the cases where staying on Cookie AutoDelete still makes sense. ## Status across browsers > **In short**: On Chromium browsers Cookie AutoDelete is disabled by Chrome's MV2 sunset; on Firefox it still works. Guardian is available and maintained on both. Browser availability is the first thing that distinguishes them. Cookie AutoDelete's core mechanism listened to tab-close lifecycle events from a persistent Manifest V2 background page and reconciled the open-tab set against the cookie store. Chrome's Manifest V3 transition removes persistent background pages in favor of ephemeral service workers, and its stable-channel sunset force-disabled all remaining MV2 extensions.[^1][^2] Cookie AutoDelete was caught in that wave on Chrome, Edge, Brave, Opera, Vivaldi, and Arc, because rewriting its tab-lifecycle logic for Manifest V3 was not on the maintainers' roadmap. On Firefox the picture is different and worth stating clearly: Firefox kept Manifest V2 support, so the maintained Cookie AutoDelete build on Firefox Add-ons continues to install and function. That is a real, ongoing capability, not a legacy footnote. Guardian, for its part, is published on the Chrome Web Store, Edge Add-ons, and Firefox Add-ons, with signed CRX side-load for Opera, Vivaldi, Arc, and Brave — so it covers the Chromium browsers Cookie AutoDelete can no longer reach, plus Firefox where Cookie AutoDelete still lives. ## Storage scope > **In short**: Cookie AutoDelete cleaned cookies and partial localStorage. Guardian cleans cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations on the same per-domain whitelist. Modern trackers hide in those side channels, so scope matters. Cookie AutoDelete focused on cookies, with partial localStorage cleanup added in later versions. That was the right scope when it was built, but tracking and session state increasingly live elsewhere — localStorage, IndexedDB, and Cache Storage can all carry an identity that survives a cookie wipe. Cleaning only cookies on tab close is now a partial defense, because a tracker can rehydrate from any side channel you left untouched. Guardian applies the same per-domain, tab-close model Cookie AutoDelete pioneered, but to every browser-storage API that can hold cross-session state: cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations. Each target is independently toggleable, so you can keep the defaults or narrow the scope if a specific site breaks. The whitelist and greylist concepts are identical to Cookie AutoDelete's — Guardian deliberately preserves the mental model and only widens what gets cleaned. ## What Cookie AutoDelete still does better > **In short**: Guardian is not strictly superior on every axis. Cookie AutoDelete is lighter, has a longer Firefox track record, and never introduced an account or Pro tier. For a Firefox-only, cookies-only workflow, those are real advantages. Honesty over marketing: Cookie AutoDelete retains a few genuine edges, and a former user deciding whether to switch deserves to hear them. - **Smaller footprint.** Cookie AutoDelete packs to roughly 150 KB; Guardian to roughly 480 KB, because the sync client and crypto library inflate the bundle. - **Longer Firefox track record.** Cookie AutoDelete has been on Firefox Add-ons since 2017 with a multi-year stability record; Guardian is newer there. - **No account or Pro tier to consider.** Cookie AutoDelete never asked you to create an account. Guardian's local-only mode is identical in that respect, but the existence of a Pro/sync tier can feel like overhead if you never use it. If you are a Firefox-only user with a stable, cookies-only whitelist, those points are a legitimate reason to stay put. We would rather you keep a tool that works for you than switch for the sake of switching. ## Feature-by-feature comparison > **In short**: The two match on the whitelist/greylist workflow, wildcards, and Firefox container support. They diverge on manifest version, Chromium availability, storage scope, and cross-device sync. The table compares Guardian and Cookie AutoDelete across the dimensions that matter to a tab-close cleanup user. Where Cookie AutoDelete leads, the table says so. | Criterion | CookieVault Guardian | Cookie AutoDelete | | --------------------------------------------- | -------------------- | ------------------- | | License | MIT (open source) | MIT (open source) | | Manifest version | V3 (current) | V2 (deprecated) | | Reproducible store build | Yes | Not documented | | Active maintenance | Yes | Slowed | | Chrome / Edge / Brave / Opera / Vivaldi / Arc | Yes | Disabled (MV2) | | Firefox | Yes (MV3) | Yes (still works) | | Tab-close auto-cleanup | Yes | Yes | | Whitelist / greylist | Yes | Yes | | Wildcard / pattern matching | Yes | Yes | | Firefox container support | Yes | Yes | | Manual "clean now" action | Yes | Yes | | Imports Cookie AutoDelete JSON | Yes | N/A (native format) | | Cleans cookies | Yes | Yes | | Cleans localStorage | Yes | Partial | | Cleans sessionStorage | Yes | No | | Cleans IndexedDB | Yes | No | | Cleans Cache Storage | Yes | No | | Cleans Service Worker registrations | Yes | No | | Cross-device whitelist sync | Yes (Pro) | No | | Approx. packed install size | ~480 KB | ~150 KB | The honest read: for Firefox-only users with a stable, cookies-only workflow, Cookie AutoDelete remains a reasonable choice. For Chromium-browser users who lost it to the MV2 sunset, cross-browser users, or anyone who wants cleanup beyond cookies, Guardian is the upgrade. ## When Cookie AutoDelete is the better choice There are honest scenarios where Cookie AutoDelete wins: - You use Firefox exclusively, where Cookie AutoDelete still installs and runs. - Your cleanup needs stop at cookies and partial localStorage, so the wider storage scope is unnecessary. - You value the smallest possible install and the lighter footprint. - You prefer a tool with no account or Pro tier in the picture at all. - Your existing whitelist and workflow are stable and nothing is broken. ## When CookieVault Guardian is the better choice Guardian fits the forward-looking and cross-browser cases: - You used Cookie AutoDelete on Chrome, Edge, Brave, Opera, Vivaldi, or Arc and lost it to the MV2 sunset. - You want auto-cleanup that covers localStorage, sessionStorage, IndexedDB, Cache Storage, and Service Worker registrations, not just cookies. - You want one whitelist synced across Firefox and Chromium browsers through end-to-end encryption. - You want a Manifest V3 architecture that will keep working through future Chrome updates. - You want reproducible builds that verify the shipped binary against open source. - You want a 90-day cookie history (Pro) to recover from accidental tab closures. ## How to migrate from Cookie AutoDelete to Guardian If Cookie AutoDelete still runs — on Firefox, or a Chromium browser not yet disabled — migration is quick. The ordered checklist: 1. Open Cookie AutoDelete's Settings and choose Export → Whitelist + Greylist; save the JSON. 2. Download the verified Guardian ZIP from the [download page](/en/download/?product=guardian) and follow the manual installation steps; store listings are not yet available. 3. Open Guardian, go to Settings → Import → Cookie AutoDelete JSON, and select the file. 4. Verify every domain appears in the Whitelist tab; subdomain inheritance is on by default. 5. Open a non-whitelisted site, browse briefly, close the tab, then reopen it to confirm cleanup ran. 6. Tune cleanup scope under Settings → Cleanup Targets, enabling or disabling each storage type. 7. Optionally enable encrypted whitelist sync under Settings → Sync to share the list across devices. 8. Uninstall Cookie AutoDelete where it still runs, keeping the exported JSON for at least 30 days as a rollback option. ## See also - [Cookie AutoDelete alternative — full migration guide](/en/alternatives/cookie-autodelete/) - [CookieVault Guardian](/en/guardian/) - [CookieVault vs EditThisCookie](/en/vs/editthiscookie/) - [Auto-delete cookies on tab close](/en/features/auto-delete-on-tab-close/) - [Cookie whitelist](/en/features/cookie-whitelist/) - [How to whitelist cookies](/en/how-to/whitelist-cookies/) --- [^1]: Chrome's Manifest V3 migration overview, including the removal of persistent background pages that Cookie AutoDelete relied on, is published at developer.chrome.com/docs/extensions/develop/migrate. [^2]: The stable-channel disablement schedule for Manifest V2 extensions is described at developer.chrome.com/blog/resuming-the-transition-to-mv3. The Cookie AutoDelete source code remains available at github.com/Cookie-AutoDelete/Cookie-AutoDelete under the MIT license. ### vs/en/cookie-editor.md --- title: 'CookieVault vs Cookie-Editor — Open vs closed comparison' slug: cookie-editor description: 'CookieVault vs Cookie-Editor compared: MIT open-source vs closed proprietary, encrypted sync vs local-only, profiles and history vs a smaller footprint. Both Manifest V3.' type: vs locale: en cluster: migration author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookievault vs cookie-editor secondaryKeywords: - cookie-editor comparison - cookie-editor vs cookievault - cookie-editor alternative - is cookie-editor open source - open source cookie editor extension - cookie-editor moustachauve intent: commercial funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Is Cookie-Editor a good extension? a: Yes. Cookie-Editor, developed by Moustachauve, is a well-built, actively maintained Manifest V3 cookie editor with a clean popup, broad browser support, and a long track record without any store-removal incidents. For users who want a minimal, no-account cookie editor it is a reasonable and trustworthy choice. The CookieVault differences are licensing transparency and the sync/profiles/history feature set, not quality. - q: Is Cookie-Editor open source? a: No. Cookie-Editor is closed proprietary software — distributed for free, but its source is not published under an OSI-approved license that independent reviewers can audit. CookieVault is MIT-licensed with reproducible builds, which is the main licensing difference between the two. This is a transparency distinction, not a claim that Cookie-Editor is unsafe. - q: Does Cookie-Editor have cloud sync? a: No. Cookie-Editor is local-only — your cookies and settings stay on the device and there is no cross-device sync feature. CookieVault offers optional end-to-end encrypted sync on its Pro tier, where the encryption key is derived on your device and the server only ever stores opaque ciphertext. - q: What does CookieVault offer that Cookie-Editor does not? a: End-to-end encrypted cross-device sync, multi-account profiles, cookie history with undo, MIT-licensed source, and reproducible Chrome Web Store builds. Cookie-Editor offers a smaller install footprint and an account-free experience. Which set matters more depends entirely on your workflow. - q: What does Cookie-Editor offer that CookieVault does not? a: A smaller packed install size (Cookie-Editor is lighter because it ships no sync client or crypto library), no account or Pro tier to think about, and a longer continuous track record in its current form. If a minimal local-only editor is all you need, those are real advantages. - q: Are both Cookie-Editor and CookieVault Manifest V3? a: Yes. Both are built on Manifest V3, so both keep working after Chrome's Manifest V2 sunset that removed older extensions like EditThisCookie and Cookie AutoDelete from Chrome. Manifest version is not a differentiator between these two. - q: Can I import my Cookie-Editor data into CookieVault? a: Yes. Both tools export cookies as JSON. Export from Cookie-Editor, then in CookieVault choose Settings → Import → JSON and select the file. Standard cookie fields — name, value, domain, path, expires, httpOnly, secure, sameSite — are carried across through the official chrome.cookies API. - q: Is CookieVault more expensive than Cookie-Editor? a: Both are free for local cookie editing. CookieVault additionally offers an optional Pro tier ($3.99/month or $29/year) for encrypted sync, profiles, and history. If you never want those features, your effective cost is the same as Cookie-Editor — zero. - q: Which should I choose, CookieVault or Cookie-Editor? a: Choose Cookie-Editor if you want the leanest possible local-only editor with no account. Choose CookieVault if you want auditable open-source code, reproducible builds, encrypted cross-device sync, profiles, or cookie history. Both are current Manifest V3 tools, so this is a genuine preference decision, not a safe-vs-unsafe one. --- # CookieVault vs Cookie-Editor > **TL;DR**: CookieVault and Cookie-Editor are both modern Manifest V3 cookie editors. CookieVault is MIT-licensed with optional end-to-end encrypted sync, profiles, and history; Cookie-Editor is a closed-source, local-only tool with a smaller footprint. Pick on transparency and sync versus minimalism. CookieVault vs Cookie-Editor is a comparison between two actively maintained Manifest V3 cookie editors that differ mainly on licensing transparency and feature breadth. CookieVault is a free, MIT-licensed cookie manager with optional encrypted cross-device sync, while Cookie-Editor (developed by Moustachauve) is a free, closed-source, local-only editor known for a clean popup and a small install size. Unlike comparisons against removed extensions, this is not a safe-versus-unsafe decision — both tools work today — so the page focuses on the honest tradeoffs between them. ## Both are current Manifest V3 tools > **In short**: Cookie-Editor is a legitimate, well-maintained Manifest V3 extension, not a deprecated or removed one. The comparison is about which feature and licensing model fits you, not about which is safe to install. It is worth stating plainly up front: Cookie-Editor is a good extension. It is built on Manifest V3, so it is unaffected by the Chrome MV2 sunset that removed EditThisCookie and disabled Cookie AutoDelete. It has a clean, fast popup, broad browser coverage, and no history of store-removal incidents. Per CookieVault's editorial policy, we compare against it on the merits and credit its strengths rather than manufacturing weaknesses. Both CookieVault Editor and Cookie-Editor use the official `chrome.cookies` API and ship across Chrome, Edge, Firefox, and other Chromium browsers. So the manifest-version axis that decides comparisons against EditThisCookie and Cookie AutoDelete is a tie here. What remains are two real differences: how the code is licensed, and how much the tool does beyond a single-device editor. ## Licensing and source transparency > **In short**: CookieVault is MIT-licensed with reproducible builds; Cookie-Editor is closed proprietary. This is a transparency difference, not a security accusation — closed source does not mean unsafe, but it does mean you cannot independently audit the binary. The clearest difference is licensing. CookieVault publishes the full client source of its Editor and Guardian browser extensions — including the client-side cryptographic boundary — under the MIT license, and ships reproducible Chrome Web Store builds, meaning an independent reviewer can rebuild the package from a tagged commit and confirm it is byte-identical to what users download. (The hosted sync service is proprietary and not self-hostable.) Cookie-Editor is distributed free of charge but as closed proprietary software; its source is not published for independent audit. To be fair and precise: closed source is not the same as untrustworthy. Plenty of reputable software is proprietary, and Cookie-Editor has earned its reputation. The distinction is that with CookieVault you can verify the cookie-handling boundary yourself or hire someone to, whereas with any closed-source extension — Cookie-Editor included — you are extending trust to the publisher rather than verifying. For some users that audit capability matters; for others it does not, and that is a legitimate position. ## Sync, profiles, and history > **In short**: CookieVault adds end-to-end encrypted cross-device sync, multi-account profiles, and cookie history with undo on its Pro tier. Cookie-Editor is local-only by design, which keeps it lean but means each device is managed separately. CookieVault's optional Pro tier adds capabilities Cookie-Editor does not target. End-to-end encrypted sync derives the encryption key on your device from a passphrase only you know, so the same cookie set and settings appear on your laptop, work machine, and home desktop while the server stores only ciphertext it cannot read. Named profiles let you keep separate cookie environments — for example, distinct logins for testing — and cookie history with undo lets you roll a cookie back one click at a time. Cookie-Editor deliberately stays out of this territory, and that is a coherent design choice rather than a missing feature. A local-only editor needs no account, no server, and no crypto library, which is exactly why its install is smaller and its mental model simpler. If you only ever manage cookies on one machine and prefer never to create an account, the CookieVault Pro features are overhead you would not use. ## Feature-by-feature comparison > **In short**: The two match on the core editing workflow and on Manifest V3 currency. They diverge on licensing transparency, install size, and the sync/profiles/history layer. The table compares the two across the dimensions that actually distinguish them. Where Cookie-Editor leads, the table says so. | Criterion | CookieVault Editor | Cookie-Editor | | ---------------------------------- | ------------------ | ------------------ | | Manifest version | V3 (current) | V3 (current) | | Active maintenance | Yes | Yes | | Store-removal history | None | None | | License | MIT (open source) | Closed proprietary | | Reproducible store build | Yes | No | | Public maintainer identity | Yes | Yes (Moustachauve) | | Per-site cookie editor popup | Yes | Yes | | Add / edit / delete cookies | Yes | Yes | | Search / filter cookies | Yes | Yes | | Bulk JSON export / import | Yes | Yes | | End-to-end encrypted sync | Yes (Pro) | No | | Multi-account profiles | Yes (Pro) | No | | Cookie history / undo | Yes (Pro) | No | | Telemetry SDKs | None | None known | | Account required | No (only for sync) | No | | Approx. packed install size | ~480 KB | ~120 KB | | Firefox / Chromium browser support | Yes | Yes | The honest summary: if you weigh source-code auditability and the encrypted-sync feature set highly, CookieVault is the fit. If you weigh a minimal footprint and an account-free, single-device experience highly, Cookie-Editor is the fit. Neither answer is wrong. ## When Cookie-Editor is the better choice There are real, honest reasons to prefer Cookie-Editor: - You want the smallest possible install and value the lighter footprint. - You only manage cookies on a single device and have no use for cross-device sync. - You prefer a tool that never asks you to create an account or consider a Pro tier. - You are happy extending trust to a well-regarded proprietary publisher and do not need to audit the source yourself. - You already use Cookie-Editor, your workflow is stable, and nothing about it is broken. ## When CookieVault is the better choice CookieVault fits a different set of priorities: - You want MIT-licensed source you (or a security reviewer) can actually audit. - You want reproducible builds that prove the shipped binary matches that source. - You want cookies and settings synced across devices through end-to-end encryption. - You manage multiple cookie environments and want named profiles. - You want cookie history with one-click undo for accidental changes. - You want a tool whose source transparency would let the community catch a future ownership change, after seeing what an opaque transfer did to EditThisCookie. ## How to try CookieVault alongside Cookie-Editor You do not have to commit blindly — run both and compare. The ordered steps: 1. Keep Cookie-Editor installed; nothing here uninstalls it. 2. Check the [download page](/en/download/?product=editor) for the verified Editor release status. The package is not yet publicly available. 3. In Cookie-Editor, export the cookies for a site you work with as JSON. 4. In CookieVault, choose Settings → Import → JSON and load that file. 5. Confirm the cookies appear with correct domains, values, and flags. 6. Compare the two popups on the same site to judge which workflow you prefer. 7. If you want sync, enable it under CookieVault Settings → Sync and add a second device. 8. Keep whichever tool fits — or keep both; they coexist without conflict. ## See also - [Cookie-Editor alternative — full comparison](/en/alternatives/cookie-editor/) - [CookieVault vs EditThisCookie](/en/vs/editthiscookie/) - [EditThisCookie alternative](/en/alternatives/editthiscookie/) - [CookieVault Editor](/en/editor/) - [Encrypted cloud sync](/en/features/encrypted-cloud-sync/) - [How to export cookies as JSON](/en/how-to/export-cookies-json/) --- [^1]: Chrome's Manifest V3 platform documentation, including why Manifest V3 extensions remain installable after the MV2 sunset, is published at developer.chrome.com/docs/extensions/develop/migrate. ### vs/en/editthiscookie.md --- title: 'CookieVault vs EditThisCookie — Objective comparison' slug: editthiscookie description: 'CookieVault vs EditThisCookie compared: Manifest V3 vs V2, open-source vs closed, encrypted sync vs local-only, available vs removed from the store.' type: vs locale: en cluster: migration author: founder-placeholder reviewedBy: reviewer-placeholder publishedAt: 2026-05-22 lastUpdated: 2026-08-10 primaryKeyword: cookievault vs editthiscookie secondaryKeywords: - editthiscookie comparison - editthiscookie vs cookievault - editthiscookie replacement comparison - is editthiscookie safe - editthiscookie removed alternative - best editthiscookie successor intent: commercial funnel: mofu schemaType: - FAQPage geoChecklist: g1_definition_first_sentence: true g2_stats_quotes_sources_per_h2: true g3_answer_capsule: true g4_table_steps_list: true g5_author_footer: true faq: - q: Is EditThisCookie still available in 2026? a: No. Google removed EditThisCookie from the Chrome Web Store on 2024-09-28 after the maintainer account was transferred and the new owner shipped policy-violating updates. New users cannot install it, and existing users cannot receive any update. The original source code remains on GitHub under its open-source license, but the official listing is permanently gone. - q: Is CookieVault a drop-in replacement for EditThisCookie? a: For the core workflow, yes. CookieVault Editor reproduces EditThisCookie's per-site popup — view, add, edit, delete, search, and bulk export/import cookies. It imports EditThisCookie's JSON export directly, preserving name, value, domain, path, expires, httpOnly, secure, sameSite, and storeId. The two differences a former user notices are a Manifest V3 architecture under the hood and an optional encrypted-sync tier EditThisCookie never had. - q: What is the difference in license between CookieVault and EditThisCookie? a: CookieVault's Editor and Guardian browser extensions are MIT-licensed — including the client-side cryptographic boundary that runs in the browser — with reproducible Chrome Web Store builds so anyone can verify the binary matches a tagged commit. The hosted sync service is proprietary and not self-hostable. EditThisCookie's source was published on GitHub, but the post-transfer store build that triggered its removal was not auditable against that source — which is precisely the supply-chain gap reproducible builds close. - q: Can I keep using my locally installed copy of EditThisCookie? a: You can for now, but it is not advisable. EditThisCookie runs on Manifest V2, which Chrome is force-disabling in the stable channel as part of the MV3 transition. Once the disablement reaches your profile, the extension stops loading and your data is locked inside it. Export and migrate while it still runs. - q: Does CookieVault collect telemetry the way the post-transfer EditThisCookie did? a: No. CookieVault ships zero analytics SDKs — no Google Analytics, no Mixpanel, no third-party trackers. A cookie-management extension that bundles telemetry has its threat model backwards. The business model is a transparent paid Pro tier, not data monetization. - q: Is CookieVault more expensive than EditThisCookie? a: Local cookie management is free forever, the same price EditThisCookie was. CookieVault adds an optional Pro tier ($3.99/month or $29/year) that unlocks end-to-end encrypted cross-device sync, cookie history with undo, named profiles, and CSV/HAR export. No tier caps how many cookies you can manage locally. - q: Does CookieVault work on the same browsers EditThisCookie did? a: It works on more. EditThisCookie was Chromium-focused. CookieVault ships on Chrome, Edge, Brave, Opera, Vivaldi, and Arc via the same Chrome Web Store build, plus a separate Manifest V3 build on Firefox Add-ons — six browser families in total. - q: When would EditThisCookie still be the better choice? a: Honestly, almost never in 2026, because it is uninstallable for new users and force-disabled on updated Chrome. The only scenario where the old binary has a residual edge is a frozen, offline, air-gapped machine still pinned to an old Chrome build where you cannot install anything new — and even there the right move is to export your cookies before that machine is ever updated. --- # CookieVault vs EditThisCookie > **TL;DR**: EditThisCookie was the dominant Chrome cookie editor for a decade, but Google removed it from the Chrome Web Store on 2024-09-28. CookieVault is the open-source, Manifest V3 successor — the same Editor workflow plus encrypted sync, reproducible builds, and a transparent owner. CookieVault vs EditThisCookie is a comparison between an actively maintained Manifest V3 cookie editor and a once-dominant Manifest V2 editor that is no longer installable. CookieVault is a free, MIT-licensed cookie manager that reproduces EditThisCookie's per-site editing workflow on every Chromium browser plus Firefox, while EditThisCookie was removed from the Chrome Web Store on 2024-09-28 and is being force-disabled by Chrome's Manifest V2 sunset. This page lays out the differences objectively so a former EditThisCookie user can decide on the evidence rather than the marketing. ## Availability and status > **In short**: EditThisCookie is gone from the Chrome Web Store. CookieVault is actively maintained and targets six browser families, but Editor distribution is still in pre-release; check the verified download status before migrating. EditThisCookie was removed from the Chrome Web Store on 2024-09-28 after the maintainer account was transferred and the new owner pushed updates with aggressive monetization that violated store policy. The original author, Francesco Capano, has publicly stated that he sold the extension years before the malicious changes and was not involved in them. The result for users is the same regardless of fault: searching the store for the original listing now returns "The item you have requested is not available," so there is no in-store path to install or update it. CookieVault, by contrast, is live on the Chrome Web Store, Edge Add-ons, and Firefox Add-ons, with signed CRX side-load packages on GitHub for Opera, Vivaldi, Arc, and Brave. We treat maintainer-account transfers as a known browser-extension supply-chain risk — the EditThisCookie story is the textbook example — and counter it with public maintainer identities and reproducible builds rather than asking users to trust an opaque publisher. ## Manifest version and longevity > **In short**: EditThisCookie is Manifest V2, the deprecated extension platform Chrome is actively disabling. CookieVault is Manifest V3 native, built on the service-worker architecture Chrome will support going forward. EditThisCookie was built on Manifest V2, the extension platform Google has been retiring since 2019.[^1] Chrome's published transition timeline disables MV2 extensions in the stable channel, with no automatic upgrade for extensions that have not been rewritten.[^2] Even if the maintainer-transfer incident had never happened, EditThisCookie would have been broken by this sunset, because its architecture relied on persistent background pages and APIs that MV3 removes. CookieVault is Manifest V3 from the ground up: an ephemeral service worker instead of a persistent background page, and the official `chrome.cookies` API for all reads and writes. You can confirm this yourself by inspecting the extension's `manifest.json` for `"manifest_version": 3`. This is the difference between an extension that will keep loading after the next Chrome update and one that will not. ## Licensing and auditability > **In short**: Both projects published source code, but only CookieVault offers reproducible builds that prove the shipped binary matches that source. The gap between "published source" and "verifiable binary" is exactly what failed EditThisCookie's users. EditThisCookie's source code lived on GitHub under an open-source license, and community forks remain visible there today. The problem was never the source — it was that the post-transfer build distributed through the Chrome Web Store could not be verified against that source. A reader had no cryptographic way to know whether the running binary matched the public code. CookieVault closes that gap with reproducible builds: each Chrome Web Store release is byte-reproducible from a tagged Git commit, so an independent reviewer can rebuild the package and confirm it is identical to what users download. The Editor and Guardian browser extensions — including the client-side cryptographic boundary — are MIT-licensed; the hosted sync service stays proprietary. Open source is necessary but not sufficient for trust; reproducibility is the part that actually defends against the attack class that removed EditThisCookie. ## Feature-by-feature comparison > **In short**: On the core cookie-editing surface the two are close, with CookieVault matching EditThisCookie's popup workflow. CookieVault then adds encrypted sync, profiles, history, and modern MV3 compatibility that EditThisCookie never had. The table below compares the two across the dimensions a former EditThisCookie user actually evaluates. Where EditThisCookie had a genuine strength, we say so. | Criterion | CookieVault Editor | EditThisCookie | | ------------------------------------ | --------------------- | -------------------------------- | | Chrome Web Store availability | Available, maintained | Removed 2024-09-28 | | Manifest version | V3 (current) | V2 (deprecated) | | License | MIT (open source) | Open-source source, opaque build | | Reproducible store build | Yes | No | | Public maintainer identity | Yes | Transferred / unclear | | Per-site cookie editor popup | Yes | Yes | | Add / edit / delete cookies | Yes | Yes | | Bulk JSON export | Yes | Yes | | Imports EditThisCookie JSON | Yes | N/A (native format) | | Search / filter cookies | Yes | Yes | | End-to-end encrypted sync | Yes (Pro) | No | | Multi-account profiles | Yes (Pro) | No | | Cookie history / undo | Yes (Pro) | No | | Telemetry SDKs | None | Present in post-transfer build | | Firefox build | Yes (MV3) | No | | Edge / Brave / Opera / Vivaldi / Arc | Yes | Chromium only, now uninstallable | The honest read: on the basic popup workflow the original EditThisCookie was perfectly capable, and CookieVault deliberately mirrors that workflow rather than reinventing it. The decisive differences are availability, manifest version, build verifiability, and the encrypted-sync feature set. ## When EditThisCookie is the better choice We will not pretend there is never a reason to prefer the old tool, but the honest list is short: - You are on a frozen, offline machine pinned to an old Chrome build where you cannot install anything new and the existing EditThisCookie copy still loads. - You only need a one-time export of cookies you already have, and the local binary still runs long enough to produce that export. - You have a specific muscle-memory dependency on EditThisCookie's exact keyboard flow and are willing to accept that it will eventually stop working. In every one of these cases the recommended action is still the same: use the working copy to export your data, then migrate, because Chrome's MV2 disablement makes the local copy a depreciating asset. ## When CookieVault is the better choice CookieVault is the better choice in essentially every forward-looking scenario: - You want a cookie editor you can actually install today, on a current browser. - You want the popup workflow to keep working after the next Chrome update, not break with the MV2 sunset. - You care that the shipped binary is verifiable against open source, not just that source exists somewhere. - You want cookies available on a second device through end-to-end encrypted sync. - You manage multiple environments and want named profiles or cookie history with undo. - You want a tool with a public maintainer and a transparent business model, after watching what an opaque ownership transfer did to EditThisCookie. ## How to switch in under two minutes If your EditThisCookie copy still runs, migration is fast. The ordered checklist: 1. Open EditThisCookie's popup while it still loads and choose Export → JSON; save the file. 2. Check the [download page](/en/download/?product=editor) for the verified Editor release status. The package is not yet publicly available. 3. Open the CookieVault popup, go to Settings → Import → EditThisCookie JSON, and select the file. 4. Confirm the cookie list populated with correct domains, values, and expiry timestamps. 5. Visit a site whose login depends on imported cookies and verify the session is active. 6. Uninstall EditThisCookie from `chrome://extensions`. 7. Optionally enable encrypted sync under Settings → Sync to make cookies available on another device. 8. Securely delete the exported JSON from disk — plaintext cookies on disk are a credential-leak risk. ## See also - [EditThisCookie alternative — full migration guide](/en/alternatives/editthiscookie/) - [CookieVault vs Cookie-Editor](/en/vs/cookie-editor/) - [Cookie-Editor alternative](/en/alternatives/cookie-editor/) - [CookieVault Editor](/en/editor/) - [How to edit cookies in Chrome](/en/how-to/edit-cookies-chrome/) - [How to export cookies as JSON](/en/how-to/export-cookies-json/) --- [^1]: Chrome's Manifest V3 migration overview and timeline are published at developer.chrome.com/docs/extensions/develop/migrate, which documents the deprecation of Manifest V2 and the APIs it removes. [^2]: The stable-channel disablement schedule for Manifest V2 extensions is described at developer.chrome.com/blog/resuming-the-transition-to-mv3.