ModHeader is gone: how to pick a replacement and move your header rules

TL;DR: ModHeader was pulled from the Chrome and Edge stores in July 2026. If you have its JSON export, keep it. Pick a replacement built on declarativeNetRequest that needs no account and no extra permissions, then import your export. Disclosure: I built one of those replacements, Headrule.

If you do API or frontend work in Chrome, at some point you needed to change a request header. Add an Authorization token to a staging environment. Pretend to be an iPhone. Patch a CORS header while developing against a local server. Chrome gives you no way to do any of that on its own, so most of us installed an extension.

For a lot of people that extension was ModHeader. In July 2026 it was removed from both the Chrome Web Store and the Edge Add-ons store, after the security firm Stripe OLT published an analysis reporting a browsing-history collector inside it. In the version they examined, the collector was switched off, and they did not observe history being uploaded. The extension is gone either way, and if you had rules saved in it they went with it.

This post covers what changed, what your options are, and how to get your header rules working again.

Why this happened at all

Header modification used to be built on the blocking webRequest API, which let an extension intercept every request, inspect it, and rewrite it in JavaScript. That is enormously powerful and enormously hard to audit, because nothing about the API forces the extension to limit itself to headers.

Manifest V3 removed blocking webRequest for most extensions and replaced it with declarativeNetRequest. The difference matters more than it sounds. With declarativeNetRequest, an extension hands Chrome a list of rules and Chrome applies them itself. The extension never sees the request. It cannot log your URLs from that API, because it never receives them.

That is a real security improvement, and it is also why a header tool written today can be meaningfully more trustworthy than one written in 2019.

What to look for in a replacement

Whatever you pick, check three things before you install it.

Does it need an account? A header modifier has no reason to know who you are. If it asks you to sign in, check what it stores and where.

What permissions does it request? A declarativeNetRequest-based tool needs declarativeNetRequest, storage, and host access. If it also asks for webRequest, scripting, or tabs, it is doing more than headers.

Is the source available? You cannot audit a minified bundle. You can audit a public repository.

Moving your rules

If you still have ModHeader installed somewhere, or you exported your profiles at some point, you have a JSON file with your rules in it. That file is worth keeping. Some replacements can read it, including the one I built. I wrote up exactly what carries over from a ModHeader export and what gets switched off or skipped, so you know what to check after importing.

If you never exported, your rules are gone and you will be retyping them. Sorry. Export early next time.

The tool I built

Full disclosure: I wrote one. It is called Headrule and the source is public.

It does one thing. Add, set or remove request and response headers, scoped by URL. Rules apply from the next request after you type them, because they go straight into Chrome's own request engine.

What it deliberately does not do: no account, no analytics, no crash reporting, no remote code, no content scripts. The only network request it makes on its own is a license check, and only if you buy the paid tier.

Free covers unlimited rules with URL filters in one profile, plus import and export including ModHeader files. Pro is nine dollars once, not a subscription, and adds multiple profiles, regex URL filters, and sync through your own Chrome account.

Things that will trip you up

A few Chrome rules that surprise people, regardless of which extension you use.

Append only works on a handful of request headers. Chrome permits appending to Accept, Accept-Language, Cache-Control, Cookie, User-Agent, X-Forwarded-For and a few others. For anything else you have to use set. Response headers can be appended freely.

Extensions can collide. If two extensions both modify the same header, Chrome evaluates the most recently installed extension first and the other one can silently lose. If a rule is not applying, check whether something else is also modifying it.

The install prompt looks scary for a reason. A rule with an empty URL filter has to apply everywhere, so most header tools ask for access to all sites up front. What matters is what the extension does with that access, so check for content scripts and extra permissions in its manifest.

Closing

The removal was a nuisance, but the underlying shift is good. A header tool built on declarativeNetRequest cannot see your requests through that API, which is exactly the part that got the old one into trouble. If you are picking a replacement, that is the property worth optimizing for.

What did you move to after ModHeader, and why? If you have an old ModHeader export that does not import cleanly into Headrule, leave a comment. I would like to see it.