Documentation — HeaderForge

HeaderForge modifies HTTP request and response headers, plus request cookies, on the sites you choose. Rules apply instantly through Chrome's own network engine, and everything you configure stays in your browser.

The full popup — profiles up top, then request headers, cookies, response headers, and URL filters.

Installing

Grab the extension from the Download page — either the Chrome Web Store listing or the local package. For the local package: unzip it somewhere permanent, open chrome://extensions, turn on Developer mode, click Load unpacked, and select the folder containing manifest.json. Pin the icon from the toolbar's puzzle-piece menu.

Where your config lives. Everything is stored inside the Chrome profile where you installed the extension. A different Chrome profile — or removing the extension — starts fresh. Use Export to keep a backup.

Request headers

Each row is one rule: an enable checkbox, an operation, a header name, and a value.

Request header rules with the operation dropdown open showing Set, Append, Remove

Each row: enable, operation, name, value — with an optional comment beneath.

Set replaces the header, creating it if absent — the common case. Append adds your value to an existing header. Remove deletes it; the value field disappears since it isn't needed.

Example — spoof a client IP for an edge test. Add a Set rule for X-Forwarded-For with value 203.0.113.7, scoped with a URL filter to your service. Your origin now sees the injected address on every matching request.

DevTools may hide request changes. In some Chrome versions the Network panel captures the request before the extension modifies it, so your header may not appear there even though the server receives it. Confirm against an echo endpoint if unsure.

Append is limited on requests. Chrome only supports Append for a fixed set of request headers (such as Cookie, Accept, User-Agent, X-Forwarded-For). An unsupported combination shows the ERR badge. Response headers support Append universally.

Response headers

Identical mechanics, but for what the browser receives — where you unblock CORS, strip or draft a Content-Security-Policy, or simulate caching.

Response header rule setting Access-Control-Allow-Origin to a wildcard

Set, append, or remove headers on the way in.

Example — unblock CORS against a nonprod API. Add a Set rule for Access-Control-Allow-Origin with value *, filtered to the API host. Cross-origin fetches now pass the browser's CORS check, because Chrome evaluates CORS against the modified headers.

The Network panel shows pre-modification headers. Your injected response header won't appear there even when the rule works. Use Verify instead.

Cached and service-worker responses bypass rules. A response from the HTTP cache or synthesized by a service worker never crosses the network stack. Test with "Disable cache" checked in DevTools.

Security headers are load-bearing. Removing CSP on sites you don't control disables real protections while the rule is active. Keep such rules tightly filtered and in a dedicated profile.

Request cookies

Cookie rules have three operations with deliberately different mechanics, because Chrome treats the Cookie header as one opaque string.

Cookie rules with append, set, and remove

Append, Set, and Remove behave differently — by necessity.

Append adds name=value to the outgoing Cookie header. It respects URL filters and never touches stored cookies. If the browser jar already sends a same-named cookie, the server sees both — so Append adds, it doesn't override.

Set writes a session cookie into the browser jar for the domain you specify — a true override, visible in DevTools → Application → Cookies. Use a leading dot (.example.com) for a domain-wide cookie.

Remove deletes the named cookie from the jar for that domain when the rule activates.

Example — plant an auth cookie on a nonprod endpoint. Add a Set rule with name auth_token, your token as the value, and domain .example.com. Activate the profile: the cookie appears in the jar and rides every request to that domain. Switch profiles or pause, and HeaderForge removes it.

Set / Remove are domain-scoped, not URL-filtered. Jar cookies attach to a domain, so a Set cookie is sent on every request to that domain while active. Only Append respects URL filters.

Remove and overwrites can't be undone. Deleting a cookie discards its value; deactivating the rule can't bring it back. If Set overwrote an existing cookie, the original is gone — the site must re-issue it.

URL filters

Filters scope where header rules and Append cookie rules apply. With no include filters, rules apply everywhere.

Include widens the match; exclude carves out exceptions that win.

The default syntax is Chrome's urlFilter format: ||example.com anchors a domain and subdomains, * is a wildcard, and ^ matches a separator. A typical pattern: ||api.example.com/v2/*. Toggle .* on a row to interpret the pattern as RE2 regex instead.

Example — keep a token off third-party sites. Include ||myapp.example.com/* so an Authorization rule fires only on your host. Or invert it: leave includes empty and exclude a sensitive host so a broad debugging header never leaks there.

RE2, not JavaScript regex. No lookahead, lookbehind, or backreferences. An unsupported pattern fails the whole rule set with an ERR badge naming the problem.

Profiles

Profiles are complete, independent configurations — headers, cookies, and filters together. Exactly one is active at a time; switching atomically swaps all rules and syncs jar cookies.

Only the active profile generates rules.

New creates an empty profile, Duplicate clones the active one, Rename edits inline (Enter commits, Esc cancels), and Delete is a two-step "Sure?" button since popups can't show dialogs.

Example — environment switching. Keep a Staging API profile (auth cookie + environment header + host filter) and a CORS testing profile (a response CORS rule). Flip between them from the dropdown; nothing from the inactive profile leaks through.

Pause is global. It suspends every profile — all rules drop and all HeaderForge-set cookies are removed — until you resume.

Verify

The Verify button answers a question DevTools can't: is my response rule actually working? It re-fetches the current tab from the page's own context and lists the response headers exactly as the renderer sees them, after modification.

Your matching rules are tagged; removals get a pass/fail verdict.

Two blind spots. Set-Cookie is never exposed to page fetch(), so cookie response headers can't be shown. And request-side changes are invisible from a response — verify those against an echo endpoint. Verify also can't run on chrome:// or extension pages.

Comments

Every header and cookie rule can carry an optional comment. Click the # button on a row to open a note line beneath it — for example, # staging bypass token, rotate each deploy. Comments never affect what's sent, are kept when a rule is disabled, and travel with the profile in exports.

The toolbar badge

The badge is the always-visible status light.

A blue number counts the enabled rules in the active profile. A gray ‖ means everything is paused. A red ERR means a rule failed to compile — open the popup for the exact error. While ERR shows, no rules apply at all; HeaderForge fails closed rather than run a partial set.

Import & export

The two arrow buttons at the right of the profile bar handle backup, device transfer, and sharing.

Export downloads all your profiles as a single JSON file. Import opens a file picker, then offers Merge (add alongside existing profiles, auto-renaming clashes) or Replace all (swap everything and activate the first import). Rules rebuild instantly either way.

To move devices: export on the old machine, install on the new one, import, choose Replace all. To share one profile: duplicate it, export, and let a colleague import with Merge.

Exports contain secrets. Header and cookie values are exported verbatim — auth tokens included. Treat export files like a .env file, and only import files from people you trust.

Add to Chrome