Last updated: September 28, 2026
HeaderForge runs entirely in your browser. Your rules stay on your machine unless you turn on sync. We collect no browsing data, no analytics, and no telemetry of any kind.
Your header rules (header names, values, URL patterns), profiles, settings and license status are stored locally in your browser using chrome.storage.local. They are never sent to us.
Match history (Pro). When you use "Test a URL" in the popup, the address you typed is kept in a list of your last 50 tests, without its query string, so you can see what matched. It stays in chrome.storage.local and you can clear it at any time in Settings.
Variables (Pro). Values you give to variables such as {{token}} are stored in chrome.storage.local on your computer. They are not synced unless you separately turn on syncing variable values, and exported rule files contain only the variable names.
Block and redirect rules are carried out by the browser itself. HeaderForge never fetches, reads or forwards the requests they affect.
Small counters. The number of free URL tests used this month and the days your rules were used (so we can ask once whether you'd like to leave a review) are kept on your computer and never sent.
Optional sync. If you switch on sync in Settings, your rules and profiles are also copied to chrome.storage.sync, which your browser's own sync carries to your other computers signed in to the same browser profile. That goes through your browser's own sync service, not through us. Rules can contain secrets such as tokens, so sync is off until you turn it on.
HeaderForge Pro can show you, in the popup, the requests the tab you are looking at is making, and which of your own header rules touched each one. Because this is the one place where the extension observes network activity, here is exactly what it does.
chrome.storage, never synced to your other computers, and never sent over the network to us or anyone else.The list is honest about what it can prove. The browser reports request headers to the extension after your rule has changed them, so a row can truthfully say a header was sent. The browser reports response headers before your rule changes them, so for a response-header rule the list only says the rule matched that response — it never claims the header was present, changed or removed.
While the popup is open on a tab, HeaderForge also keeps a much shorter list drawn from the same recording: the servers whose answers the browser will not let that page read. It is what the popup uses to say "api.example.com blocked a request from this page (CORS)" and to offer the one-click fix, which is free. It lives under the same rules as the list above — that one tab, the background worker's memory, only while the popup is open, dropped when the popup closes, never written to storage and never sent anywhere.
http://localhost:3000), whether the failure was a rejected preflight, and the time. At most 20 servers per tab. No address path, no query string, no headers, no bodies.HeaderForge's handling of user data complies with the Chrome Web Store User Data Policy, including its Limited Use requirements. The data described above is used for one purpose only — showing you which of your own rules affected which request, on your own screen. It is never transferred off your device, never sold, never used for advertising or profiling, never used to train models, and never read by a human.
If you choose to activate HeaderForge Pro, the extension sends your license key to Lemon Squeezy (our payment provider, lemonsqueezy.com) to verify it. That happens when you activate, and then at most once a day while Pro is on, so that Pro switches off if your subscription ends. If you never activate Pro, the extension never sends it. Your email address, if returned by Lemon Squeezy during validation, is stored locally to display your license status. The request goes to exactly one address, https://api.lemonsqueezy.com/v1/licenses/validate, and contains exactly one thing: your licence key. No page data, no identifiers, nothing about what you were doing.
The welcome page has a button labelled "Send 3 test requests to httpbin.org". Only if you click it, the page sends three test requests to https://httpbin.org/anything, a public service that echoes back what it received. They exist to prove your test rule works, and they carry the test header X-HeaderForge-Test: hello and nothing else about you. Apart from these and the licence check, the extension makes no network requests. You can confirm this by searching the extension's source for fetch(: it appears in common.js for the licence check and in welcome.js for the test.
HeaderForge requests access to all websites (<all_urls>) for one reason only: modifying HTTP headers requires the browser's network-layer permission on the sites you target. Header rules are applied locally by the browser itself; the extension does not read page content.
It also requests webRequest, which it uses in observe-only mode for the live request list and the CORS notice described above. Headers are still modified by declarativeNetRequest, not by this permission. Because HeaderForge already has access to all websites, adding it does not widen what the extension can reach, and the browser shows no additional permission warning.
Questions: sapirsoftware@gmail.com