Does Header Modifier also change response headers?

No. It only modifies request headers — what your browser sends to the server. Response headers (what the server sends back) are completely untouched. If you need to change response headers, you need a proxy or a server-side change.

Will my custom headers apply to curl or Postman requests?

No. Rules apply only to requests made by that Chrome browser instance. Curl, Postman, CI runners, backend-to-backend calls — none of those go through Chrome, so none are affected. This is a browser-level tool, not a system-wide proxy.

I set a header but it doesn't seem to be working. Why?

A few possibilities: Chrome silently blocks modification of certain protected headers (like Host, Content-Length, and a handful of others defined by the Fetch spec). If your rule targets one of those, it will be dropped with no error message. Also check that your URL pattern actually matches the request — use wildcards if needed.

Is it safe to leave rules on permanently?

For development headers scoped to a staging domain, yes. But broadly-scoped rules (like *://*/*) applied to production URLs can cause confusion when you forget about them, especially if you're sharing a laptop or debugging something months later. The master switch is exactly for this — leave rules intact but switch them off when not actively testing.

Does the extension log or store my header values anywhere?

No. Header Modifier stores rules in Chrome's sync storage, which means they follow your signed-in Chrome profile across devices. The extension itself does not send any data to external servers — it has no backend, no analytics, and no account system.

What's the difference between the per-rule toggle and the master switch?

Per-rule toggles let you enable or disable individual rules. The master switch disables the entire extension at once — all rules are inactive until you flip it back on. Think of the master switch as a circuit breaker for when you're done with a testing session and just want everything off without touching individual rules.

How to Modify HTTP Request Headers in Chrome Without a Proxy (2026)

You're testing an API endpoint that checks for a custom header before returning certain data. Or you're trying to preview a feature behind a flag that your staging server reads from a request header. The obvious tools — curl, Postman — work, but they're disconnected from the browser session that already has your auth cookies, your local storage state, your WebSocket connections. Replicating that in Postman takes 15 minutes and you'll miss something.

What you actually want is to add the header directly to Chrome. No proxy. No extra tool. No request interception that breaks your CORS setup.

That's what Header Modifier does. It's free on the Chrome Web Store, takes two minutes to set up, and stays completely out of the request path — it doesn't proxy or inspect your traffic.

How It Works Under the Hood

Header Modifier is built on Chrome's Manifest V3 declarativeNetRequest API. Instead of sitting between you and the network (like a proxy does), it registers rules with Chrome's own networking layer. Chrome applies the rules itself, before requests leave the browser. The extension never reads your page content, never sees response bodies, and has no access to your browsing history.

Each rule is three fields: the header name, the value, and a URL pattern that determines which requests it applies to.

One important constraint: it modifies request headers only. Not response headers — those come from the server and are out of scope. If someone told you this extension could modify what a server sends back, that's not accurate.

Setting Up Your First Rule

Install Header Modifier from the Chrome Web Store, then click the extension icon in your toolbar.

Hit "Add Rule." You'll see three fields:

Header name — whatever you want to inject. X-Feature-Flag, X-Internal-Test, Authorization, X-Tenant-ID. Standard or custom, your call.

Value — the string you want sent.

URL pattern — this is where you scope the rule. *://staging.yourapp.com/* restricts it to a single environment. *://*.yourapp.com/* hits staging and production both. The second form makes most people nervous the moment they accidentally trigger a staging behavior in production — scope it tight.

Save, toggle the rule on. That's it.

Verifying It's Actually Firing

Open Chrome DevTools with F12, go to the Network tab, and make a request to a URL that your pattern matches. Click the request, then look at the Headers tab and scroll to "Request Headers." Your header should be there.

If it's not there, two things to check:

URL pattern mismatch — the pattern didn't match. Double-check the scheme, domain, and path. Try a broader wildcard temporarily to confirm the extension is working at all.
Protected header — Chrome silently drops rules that target certain headers it controls. Host, Content-Length, Origin, Referer, and a few others defined in the Fetch specification cannot be overridden by extensions. There's no error; the rule just does nothing. If you're targeting one of these, you're out of luck without a proper proxy.

The Master Switch Is More Useful Than It Sounds

Every developer I know who uses a header extension has accidentally left a test header on and spent 20 minutes debugging why their app behaved weirdly on a call with a client. The master switch in Header Modifier disables every rule simultaneously — no need to remember which ones you had active or hunt through a list.

Get in the habit: testing session starts, flip the master switch on. Session ends, flip it off. The rules stay intact for next time. This is fundamentally different from deleting rules, which you'd have to recreate. The master switch is the off ramp.

Rules Live in Your Chrome Profile

Header Modifier stores rules in Chrome's sync storage. That means they follow you across Chrome on your other machines as long as you're signed into the same Google account. Useful if you have a desktop and a laptop both hitting the same staging environment — set up the rules once.

The flip side: if you add a broad rule and then forget about it, it'll show up on your other machine too. Scope your URL patterns defensively.

What It Can't Do

To be concrete about the boundaries:

Response headers: not modifiable. What the server sends back is the server's business.
Non-Chrome requests: curl, wget, Postman, your backend services, CI pipelines — nothing outside Chrome.
Some request headers: Chrome's protected list. Silent failure.
Request body: no — this is header modification only.
Traffic inspection: Header Modifier cannot read your page content, response bodies, or request payloads. It doesn't log what you send or receive.

For anything beyond these boundaries, you need a proxy tool (Charles, mitmproxy, Burp Suite) or a browser-level DevTools override.

For the use case it covers — injecting custom headers into specific browser requests without disrupting anything else — it's the simplest option available. Install it from the Chrome Web Store and find more developer tooling resources at /developers.