Cookie extensions reviewed: Cookie-Editor, Cookie AutoDelete & the banner blockers
Cookie extensions touch your session tokens and every site you visit. I compared Cookie-Editor, Cookie AutoDelete and the banner blockers on who owns them.

Cookie extensions are the category I get asked about most and trust least. Not because the popular ones are bad — several are genuinely good — but because this corner of the store has a worse ownership track record than almost any other. Two of the four best-known names in it have changed hands, and both times it went badly for users.
That matters more here than in most categories, because of what these extensions touch. A cookie editor can read the token that keeps you signed into your bank. A banner blocker runs a script on every page you load. Neither is inherently sketchy — both need that access to work — but it means the only real question in this review is who is on the other end of it.
Quick verdict
- Cookie-Editor — my pick if you actually need to inspect or edit cookies. Open source under GPL-3.0, and its Chrome manifest keeps host access optional rather than demanding all sites up front. That single design choice puts it ahead of the field.
- Consent-O-Matic — the banner blocker I'd install. Built by researchers at Aarhus University's CAVI centre, open source under MIT, and it rejects tracking consent instead of just hiding the popup.
- Cookie AutoDelete — beloved, and effectively over on Chrome. The Manifest V3 migration never shipped (issue #1634 is still the tracking ticket). The Firefox build is where it still lives.
- "I don't care about cookies" — works fine, but it's been an Avast property since September 2022. Whether that bothers you depends on how you read the FTC's 2024 order against Avast, which I'll get into below.
- EditThisCookie — gone, and the thing wearing its name is not it. Don't reinstall from memory.
What cookie extensions actually do
Two different jobs get lumped under "cookie extension," and they carry different risks.
Cookie editors and cleaners — Cookie-Editor, Cookie AutoDelete, the late EditThisCookie — talk to the browser's cookie store directly. They list, edit, export and delete the actual cookie values for a site. Developers use them constantly for testing sessions; privacy-minded users use them to nuke tracking cookies when a tab closes.
Banner blockers — Consent-O-Matic, "I don't care about cookies," and its community fork "I still don't care about cookies" — never touch the cookie store at all. They run a content script on the pages you visit and deal with the consent popup, either by hiding it or by filling it out.
Same shelf in the store, completely different threat models. A compromised banner blocker is a script on every site you load. A compromised cookie editor is your session tokens.
Security analysis: why a cookie editor is a bigger deal than it looks
The cookies permission is the one people skim past, and it's one of the most consequential entries on a manifest. It doesn't just read the tracking junk — it reads session cookies, including httpOnly ones that page JavaScript is deliberately forbidden from seeing. I broke that down properly in my earlier piece on the cookies permission, but the short version: a cookie value is often a live, working login. Copy it, replay it, and you're in the account without a password or a 2FA prompt.
So the bar for a cookie editor is high. This is where Cookie-Editor's design choice earns its recommendation. Its Chrome manifest requests cookies, tabs, storage and sidePanel, and lists host access to all URLs as an optional permission — meaning you grant it per-site rather than handing over everything at install. Most of the category asks for the lot on day one.
Banner blockers get judged on the other axis. They don't want your cookies, they want to run on every page — and a content script on every page can read and rewrite whatever's on it. That's a lot of latent capability sitting in an extension whose visible job is dismissing a popup.
The real risk here is ownership, not permissions
Here's why I lead with who owns these things.
EditThisCookie is the cautionary tale. The original extension left the Chrome Web Store, and — as gHacks reported in December 2024 — a copycat listing calling itself "EditThisCookie®" stayed up and kept growing, reaching tens of thousands of users. Malware analyst Eric Parker's teardown of the fake, covered by both gHacks and TechSpot, found obfuscated code and links to a fraudulent site. Worth being fair about the limits of that finding: per those reports, Parker did not find cookie-exfiltration code in the version he analysed. The concern was that automatic updates mean today's build isn't a promise about tomorrow's.
That's the same shape as the ownership-transfer attacks I've written about before: the name you trust and the code you're running stop being the same thing, quietly. There's now an "EditThisCookie (V3)" listing on the store as well; I can't verify its lineage back to the original project, so I'm not recommending it either way. Install Cookie-Editor and skip the question.
The Avast question is more nuanced, and I want to state it precisely. "I don't care about cookies" was acquired by Avast in September 2022, announced on the extension's own site by its developer, who said it would stay free and that he'd keep working on it. Separately, in February 2024, the FTC ordered Avast to pay $16.5 million and banned it from selling browsing data for advertising, over allegations that it collected consumers' browsing data through its antivirus and browser extensions and sold it via its Jumpshot subsidiary — as reported by The Record and others.
Two things are true at once. The conduct the FTC described ran from 2014 to 2020, which is before the extension was acquired, and none of it concerns this extension. And equally: it's reasonable to weigh a company's documented history when deciding who gets a script on every page you visit. As of August 2026, I haven't found any public statement from Avast or Gen Digital specifically addressing this extension's data practices since the acquisition post. If one exists or arrives, I'll update this.
That's not an accusation — it's the trust calculation, laid out. Make it yourself.
Privacy score breakdown: the axes that actually matter
I'm not going to invent a "9.2/10" for you. Here's what Extenshi's scanner weighs on this category, and roughly where each lands.
Permission breadth
Cookie-Editor wins on optional host permissions. Consent-O-Matic needs to read pages to find the popups it knows how to handle, which is inherent to the job. Cookie AutoDelete's Firefox listing asks for all-sites data access plus browsing-data clearing — again, inherent, since deleting site data by domain requires it.
Auditability
Cookie-Editor (GPL-3.0), Consent-O-Matic (MIT) and Cookie AutoDelete (MIT) are all open source with public repos. "I don't care about cookies" is the odd one out on this axis, which is exactly why the community fork exists.
Maintenance
This is where Cookie AutoDelete falls down on Chrome. Google's official timeline puts the final Chrome Web Store removal of remaining Manifest V2 listings at August 31, 2026. That date is the store-listing purge, not another browser disable — Chrome itself stopped running MV2 back in July 2025, which is the Chrome 150 sunset I wrote up earlier. A one-maintainer project that didn't make the migration is a stranded extension, and stranded extensions are exactly what gets bought and repurposed.
Consent handling
Only Consent-O-Matic actually answers the popup on your behalf according to preferences you set, and its rule set covers 200-plus consent platforms. It came out of a research group at Aarhus University, which is an unusual pedigree for a store listing and a welcome one. Hiding a banner leaves the consent state undefined; rejecting it is a different outcome. That distinction is the whole reason I rank it first among the blockers.
What I'd actually install
If you're a developer who needs to inspect cookies: Cookie-Editor, granting host access only where you need it.
If you just want the banners to stop: Consent-O-Matic — also on Firefox — because rejecting consent beats hiding the question.
If you're already running "I still don't care about cookies" and happy with it, that's a defensible choice — it's open source and community-maintained, which is more than the original listing offers.
If you want automatic cookie cleanup on Chrome specifically, you're in an awkward spot right now. Chrome's own Settings → Privacy and security → Third-party cookies and per-site "delete data on close" controls cover a good chunk of what Cookie AutoDelete did, without adding an extension that can read every cookie you own. On Firefox, just keep using Cookie AutoDelete.
And whatever you pick: check what you've already got. If a cookie extension has been sitting in your toolbar since 2021, you have no idea who owns it now. npx @extenshi/guard scan reads the extensions installed in your browsers and flags the ones with heavy permissions — no account needed for the scan.
Final recommendation
Cookie extensions are worth having. They're just the category where "it still works fine" is the least useful signal you can go on — EditThisCookie worked fine right up until the thing wearing its name wasn't it.
Pick the ones you can audit, grant host access narrowly, and re-check ownership once a year. That's the whole discipline.
See the security report for your cookie extensions → — permissions, publisher, and update history for every listing in the category, side by side. Or start from the catalog homepage and search whatever's in your toolbar right now.
Sources
- FTC Order Will Ban Avast from Selling Browsing Data for Advertising Purposes, Require It to Pay $16.5 Million — Federal Trade Commission
- FTC hits Avast with $16.5 million fine over allegations of selling users' browsing data — The Record
- "I don't care about cookies" acquired by Avast — official announcement
- EditThisCookie Chrome extension removed instead of malicious copycat — gHacks
- Chrome Manifest V3 blamed for security risks as EditThisCookie extension becomes a victim — TechSpot
- Manifest V2 support timeline — Chrome for Developers
- Cookie-Editor Chrome manifest — Moustachauve/cookie-editor on GitHub
- Cookie AutoDelete — MV3 migration tracking issue #1634 on GitHub
- Cookie AutoDelete on Firefox Add-ons
- Consent-O-Matic source repository — cavi-au on GitHub
- Aarhus researchers free users from annoying cookie pop-ups — Aarhus University
- Consent-O-Matic on Firefox Add-ons
This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If any entity referenced in this article believes information is inaccurate, contact [email protected] and we will review and update.
Related Articles
The `cookies` permission explained: what browser extensions can really access in your sessions
The cookies permission lets extensions read, write, and delete cookies — including session tokens. Here's what that means for your accounts and how to check.
Extension ownership transfers: how to protect yourself when your add-on changes hands
QuickLens got hijacked via an extension ownership transfer to push ClickFix and crypto-stealing malware. Here's how to check your own add-ons are still safe.

We counted what Chrome's Manifest V2 sunset actually removed — and it wasn't the ad blockers
Everyone said Chrome's Manifest V2 deadline would kill ad blockers. Here's what the sunset actually stranded — and why Firefox is now the MV2 refuge.

Abandoned browser extensions: how to check the add-ons that stopped getting security updates
Two-thirds of Edge extensions and half of Firefox add-ons sit abandoned — no security update in a year. Why stale extensions are risky and how to check yours.