EditThisCookie had millions of users. It was the default answer to "how do I edit cookies in Chrome?" for a decade. Then Chrome's Manifest V2 platform was retired, the extension never migrated, and in late 2024 it disappeared from the Chrome Web Store.
What happened next is the part nobody warned anyone about: a malicious clone took its name.
The clone
An extension called "EditThisCookie®" — note the ®, the dead giveaway — appeared on the store and got downloaded by tens of thousands of people searching for the original. Security researchers confirmed it was malware: obfuscated code, phishing and ad-injection mechanisms, and the ability to steal sensitive data, especially when you were logged into Facebook.
Google eventually removed it. But think about what that means: people who just wanted to edit a cookie — the most innocuous developer task imaginable — installed malware, because the tool they'd trusted for years vanished without a farewell and the search results were a minefield.
That's the real lesson of the MV2 migration: a cookie editor is a session-instrument tool. It has access to your cookies on every site. When an unmaintained cookie editor dies, its name becomes a honeypot. Whatever you install next needs to be auditable.
The checklist I now apply to any cookie editor
- MV3-native — if it's not built for Manifest V3, it's already dead, just not buried
- Open source — a cookie editor that you can't audit is a liability you're choosing
- Recent updates — check the store's "last updated" date
- No lookalike branding — any extension that brands itself as "the replacement for the dead original" deserves extra scrutiny
-
The right permissions —
cookiesis expected; broad host permissions without a clear reason are not
What to actually use in 2026
I tested the current field so you don't have to re-run this gauntlet. Full disclosure: I built one of these (CrumbKit), so take my ranking with that in mind — I've flagged where mine is genuinely weak.
Chrome DevTools — the zero-install baseline. Right-click → Inspect → Application → Cookies. Fine for the occasional edit, painful as a daily workflow. No search across domains, no. export/import.
CookieMate — open source (MIT), MV3-native, and the one feature that matters most for ex-EditThisCookie users: it imports EditThisCookie's JSON backups directly. If you have an old export, this is the smoothest migration. Simple editor, no fancy extras.
CookieJar — the feature-rich contender: cookie classification, per-site privacy scores, profiles (dev vs. prod cookie sets), multiple export formats, CHIPS partitioned-cookie support.
Free tier plus a paid Pro tier. Honestly the closest thing to "EditThisCookie with a 2026 paint job."
CrumbKit — the one I built: everything free, MIT open source, zero network requests. Where it genuinely beats the others: a Set-Cookie interceptor that shows you which cookie a server just set (in the response headers) and adds it with one click — no other tool in this list does that. Plus scheduled auto-cleanup, 6 export formats (JSON, Netscape, cURL, CSV, Puppeteer, Set-Cookie headers), batch editing, profiles, and a privacy score. Where it loses: it's younger than the alternatives and I'm a solo maintainer — if you only edit a cookie once a month, DevTools is genuinely enough.
Migrating your old backups
If you still have an EditThisCookie export: CookieMate imports its JSON format directly, and CrumbKit imports JSON and Netscape. If you don't have a backup, re-login to your sites — the old cookies are gone either way.
The takeaway
The MV2 migration didn't just break extensions — it created a trust vacuum that scammers filled within weeks. The defense isn't "find the most popular replacement." It's "find the one you can audit." Open source, zero telemetry, and a recent update date beat a familiar name every time.
If you've got a horror story from the EditThisCookie aftermath — or a cookie workflow you can't live without — drop it in the comments. I'm building feature lists off those answers.
Top comments (0)