HeaderEditor and the browser level request editor

A request editor that runs inside the browser

Header Editor is an extension that can modify the request, including request headers, response headers, response body, and can redirect requests and cancel them. It is written in TypeScript and runs in Firefox, Chrome and Edge, and the project states plainly that it is 100% free, with no ads and no data collection.

The capability list maps to real troubleshooting and development work. Rewriting a request header lets you test how a server behaves with a different User-Agent or an added authentication token. Rewriting a response header lets you remove a Content-Security-Policy, expose a header the page hides, or spoof a CORS header while testing a cross origin call. Rewriting the response body lets you change what a page actually receives, which is how you test a frontend against a modified API response. Redirecting and cancelling requests let you block an analytics endpoint or point a request at a different host.

The audience is a frontend or backend developer debugging an integration, a security researcher studying how a site behaves with different headers, and anyone who wants to see what a third party script is really doing on a page. The browser local placement is the key architectural decision. There is no companion daemon, no certificate to install into the system trust store and no configuration outside the browser profile, and the rules live in the extension's own storage.

The documentation site is at he.firefoxcn.net, and the repository has a Discussions board, a build status badge, and store links for all three browsers.

Two builds, and what v2 and v3 actually mean

The extension ships in two variants, Lite and Full, and the download table shows which browsers get which. Firefox has both, with the Lite version on Mozilla Add-ons and the full version available both there and from the official download. Chrome has the Lite build on the Chrome Web Store and the full version installed through a separate guide on the documentation site. Edge has only the full version, from the Edge Add-ons store, and no Lite build at all.

The file naming encodes the variant, with the documentation stating that HeaderEditor-xxx-v2 is the full version and HeaderEditor-xxx-v3 is the lite version. That is worth internalising before you download anything, because the two suffixes sit next to a version number that also looks like a version number, and picking the wrong one is easy.

The difference between them is documented separately on the site, at a page comparing the lite and full versions. The broad strokes are predictable from the permission list, since the Lite build does not ask for the ability to modify response bodies, which in Chrome is what the debugger permission is for.

One operational detail deserves attention. The project notes that the official download is exactly the same as the Mozilla Add-ons build, but that the Mozilla Add-ons review is very slow, usually taking more than a week, and that you may not be able to get the latest version. So for Firefox there is a genuine choice between convenience and currency, and for a tool you intend to rely on while debugging, the GitHub release is the one that carries the newest build.

The permission list is the design in miniature

The README documents the permissions the extension asks for, and reading them tells you how the thing works.

The tabs permission is for opening links such as the options page. The request modification capability comes from webRequest, webRequestBlocking, declarativeNetRequest and the *://*/* host pattern, which together allow the extension to intercept traffic. storage and unlimitedStorage hold the rules and settings, with unlimited storage there because a rule set can grow large.

Two permissions are more specific. The debugger permission is used to modify the response body in Chrome, which is the technically difficult half of the feature set, since a browser extension normally has no way to rewrite the bytes of a response it forwards. And unsafe-eval exists to execute a custom function, with the code pointed at in the repository at src/share/core/rule-utils.ts, and the README notes that the location may change and can be found by searching for new Function.

That last point is the one to weigh. The unsafe-eval permission is what makes user written transformation functions possible, and it is also the permission that makes a security reviewer stop. The project is transparent about where it is used, which is more than most, but a custom JavaScript function running inside a privileged extension is a real attack surface if a rule set is imported from an untrusted source.

The overall picture is a tool that intercepts all traffic of the browser it runs in. That is inherent to what it does, and the host permission of *://*/* is the price of applying rules everywhere rather than per site.

Building from source means four target bundles

The build documentation is concrete. You need Node.js 24.x and pnpm 11.x, then clone the project or download the source and extract it, then install dependencies with a frozen lockfile:

pnpm i --frozen-lockfile

The build command depends on the browser and the variant you want, and there are four of them:

npm run build:chrome_v2
npm run build:chrome_v3
npm run build:firefox_v2
npm run build:firefox_v3

The results land in directories named dist_*, one per target. For development, the instruction is to modify the start command's TARGET_BROWSER to the version you want to build, run npm run start, and then load the extension in the browser from the /dist_* directory or from /dist_*/manifest.json.

That last step is the one that differs from a normal web project. The thing under test is the extension itself, so the loop ends by reloading the unpacked extension in the browser's extension page. The package manifest makes the mechanism explicit, with the start script setting TARGET_BROWSER to chrome_v3 and running rsbuild dev, and each build script setting a different TARGET_BROWSER and running rsbuild build. The bundler is rsbuild, configured in rsbuild.config.ts, and the linting and formatting are done by Biome through the biome check and biome format scripts.

The dependency list shows the front end is a React 18 application using the Semi UI component library, a CodeMirror editor for writing rules, webextension-polyfill for the cross browser API layer, re2js for regular expressions, and lodash-es, dayjs, query-string and ahooks as the usual supporting libraries.

The test suite expects a local PHP server

The test scripts in the package manifest are unusual enough to be worth reading. The unit and end to end suites both run mocha with a per area configuration file, and both pass the Node option --experimental-vm-modules, which suggests the tests import ES modules directly rather than going through a transpiler for the test run.

The end to end suite needs a server to talk to, and the project provides one in the shape of a PHP built in server pointed at a fixture directory:

php -S 0.0.0.0:8899 -t tests/simple-server

The script is named run-test-server, and it binds to all interfaces on port 8899 rather than to localhost, which is a choice worth noting in a test fixture. The tests themselves live in a tests/ directory with separate unit and e2e subdirectories, each carrying its own .mocharc.json.

The repository layout also shows where the rest of the project lives. The extension source is in src/, the translations in locale/ with the English strings in locale/original/messages.json, the documentation in docs/, the static assets in public/, the build scripts in scripts/, and a patches/ directory that presumably holds patches applied to dependencies during the build. There is a pnpm-workspace.yaml, an extension.json describing the extension metadata, and a biome.json for the lint configuration.

Translations are managed on Transifex for every language except the ones the browser cannot support, which the README points out with the example of zh-Hans.

GPL-2.0 with an AI use clause, and EdgeOne paying the bills

The licence is GNU GPL v2.0 or later, copyright the FirefoxBar Team from 2017 to 2026. On top of the standard terms, the README states that unauthorized use for training, imitation, learning, generation, or related activities in the field of artificial intelligence is prohibited.

That clause is unusual and worth thinking about carefully. GPL-2.0 does not include a restriction on a particular field of use, and adding one is not something the GPL itself provides for, so the practical question is whether the additional term is enforceable and whether it conflicts with the GPL grant. For most users the answer does not matter. For an organisation that trains models, builds datasets from source code, or feeds repositories into an automated pipeline, the clause is the first thing to read, and to raise with the maintainers if it matters to you. The README also points to the licence file at the root of the repository.

The other notable line in that section is the sponsorship. CDN acceleration and security protection for the project are sponsored by Tencent EdgeOne, which is a useful reminder of what the project actually needs to operate, a CDN in front of the documentation site, and of who is paying for it.

On maintenance, the repository is not archived and the last push was on 2026-10-15, with release 5.5.0 published the same day, 5.4.3 and 5.4.2 both on 2026-10-03. The version field in the package manifest reads 5.1.0, which is behind the tags, so the manifest is not the place to look for the current version, and the release page is.

Editorial conclusion

Adopt Header Editor if you need to inspect or rewrite HTTP traffic for one browser and do not want a system wide interceptor with a certificate installed, since the extension stays inside the browser and the project states it collects no data. Do not adopt it if you need to intercept traffic from other applications on the machine, since a local proxy is the tool for that, and note that the full build on Chrome requires following the separate install guide rather than a store click. Verify three things first: which variant you need, since the v2 and v3 suffixes distinguish full from lite and Edge has no lite build, that the permissions you are granting match what you need, and whether the AI use clause in the licence is acceptable for your organisation. The last push was on 2026-10-15 and the newest release is 5.5.0 from the same day.

Frequently asked questions

Official sources

1. FirefoxBar/HeaderEditor on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases