How to Override HTTP Response Headers in Chrome (No Proxy Required)

Response headers control some of the most important browser behaviors: caching, cross-origin permissions, content security policy, and more. When you need to test how your app behaves under different header conditions, the usual options are annoying:

Change your server config and redeploy
Stand up a proxy (Charles, Fiddler, mitmproxy) to intercept and rewrite headers
Ask backend to add a debug endpoint that returns modified headers

All of this is a lot of setup for what is fundamentally a local testing problem. If you want to see how your frontend behaves when a Cache-Control: no-store header is present, you don’t need a proxy chain — you need a way to override what Chrome sees.

That’s what response header modification in HeaderSnap does. This guide shows the exact workflow for the three most common cases: Cache-Control, Access-Control-Allow-Origin, and Content-Security-Policy.

How Response Header Overrides Work in Chrome

Chrome’s declarativeNetRequest API (Manifest V3) allows trusted extensions to modify HTTP request and response headers before they reach page JavaScript. HeaderSnap uses this API exclusively — no background proxy, no persistent service worker intercepting traffic.

When you create a response rule in HeaderSnap, Chrome applies it natively at the network layer. The modified header is what the browser sees; your server is unaffected.

The 3-Step Workflow

Step 1: Open HeaderSnap and create a new rule

Click the HeaderSnap icon in your Chrome toolbar to open the popup. In the Rules tab, click Add Rule.

You’ll see a form with these fields:

Label — optional, auto-generated from the header name if left blank
Header Target — two buttons: Request and Response — select Response
URL Pattern — the URLs this rule applies to (glob or regex)
Header Name — the response header you want to override
Action — Set, Append, or Remove
Header Value — the value to set (not required for Remove)

Step 2: Configure the rule

Enter your URL pattern and header details. For example, to override Cache-Control on all requests to your local dev server:

Header Target: Response
URL Pattern: localhost:3000/*
Header Name: Cache-Control
Action: Set
Header Value: no-store

Click Add.

Step 3: Verify in Chrome DevTools

Open DevTools (F12), go to the Network tab, and reload the page. Click any request in the list, then click the Headers tab. Under Response Headers, you’ll see your overridden value.

The override is active as long as the rule exists and the profile is enabled. To test both states — with and without the header — toggle the rule on and off using the checkbox in the Rules list.

Three Common Use Cases

1. Testing Cache-Control Behavior

You want to verify that your frontend handles caching correctly — specifically, that pages don’t serve stale content when Cache-Control: no-store is set, or that assets cache correctly when max-age is extended.

Instead of changing your server configuration, create a response rule:

Header Name: Cache-Control
Action: Set
Header Value: no-store (or max-age=0, or public, max-age=3600)
URL Pattern: localhost:3000/*

Reload and observe caching behavior in the Network tab. The (from disk cache) vs fresh request behavior changes immediately.

2. Testing CORS Responses

CORS is a response-side behavior. The Access-Control-Allow-Origin header is what your browser reads to decide whether a cross-origin response is allowed. If you’re debugging a CORS issue and want to confirm your frontend handles a permissive response correctly — or test what happens when the header is absent — override it locally:

Header Name: Access-Control-Allow-Origin
Action: Set
Header Value: * (or your specific origin)
URL Pattern: api.example.com/*

This lets you isolate whether a CORS failure is a frontend or backend issue without touching either environment.

3. Tightening or Relaxing CSP in Development

Content-Security-Policy errors can be hard to debug because they block resources silently. Two scenarios come up often:

Simulating a stricter policy: Your production CSP blocks inline scripts. Your dev server doesn’t. Add a response rule setting Content-Security-Policy to your production policy value on localhost to catch violations before they hit prod.

Removing a blocking policy temporarily: A third-party API or dev dependency is being blocked by an existing CSP. Remove the header temporarily to confirm that’s the cause, then address the policy properly.

Header Name: Content-Security-Policy
Action: Set (or Remove)
Header Value: default-src 'self'; script-src 'self' (or leave blank for Remove)
URL Pattern: localhost:*/*

Using the URL Tester

Before relying on a rule in an important testing session, use HeaderSnap’s Test tab to verify it matches the URLs you expect. Enter a URL and the panel shows which rules match, including the header target (request or response) and the action that would apply. This catches pattern mistakes before they affect your test results.

When Overrides Apply

Response header rules apply to all matching HTTP responses Chrome receives — including XHR/fetch requests, document loads, and subresource requests. URL patterns can be glob (*.example.com/*) or regex, giving you precise control over scope.

Rules are stored per profile. If you use HeaderSnap’s profile system to separate dev, staging, and production configurations, response header overrides follow the same profile switching — switch profiles and your header overrides switch with them.

Summary

To override response headers in Chrome without a proxy:

Open HeaderSnap → Add Rule → set Header Target to Response
Set your URL pattern, header name, action, and value
Verify in DevTools → Network → Headers → Response Headers

No proxy setup. No backend changes. No redeployment.

HeaderSnap is a free Chrome extension with no analytics and no ads.