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 current. New users cannot install EditThisCookie at all, and existing installs receive no updates. CookieVault is published and actively maintained across six browser families.

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.¹ Chrome’s published transition timeline disables MV2 extensions in the stable channel, with no automatic upgrade for extensions that have not been rewritten.² 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 whole stack — Editor, Guardian, the sync server, and this website — is MIT-licensed. 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.

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. Install CookieVault Editor from the Chrome Web Store (or Edge / Firefox add-on sites; side-load the signed CRX for Opera / Vivaldi / Arc / Brave).
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
• CookieVault vs Cookie-Editor
• Cookie-Editor alternative
• CookieVault Editor
• How to edit cookies in Chrome
• How to export cookies as JSON