You need every request to carry a header — an Authorization token, an X-Api-Key, a feature flag, a different Accept-Language — while you test in a real browser. Here's what Chrome can do on its own, and how to do the rest.
| Want to | Built into Chrome? |
|---|---|
| Change the User-Agent | Yes — DevTools → Network conditions (how) |
| Override a response header | Yes — DevTools → Sources → Overrides, then right-click a request in Network → Override headers |
| Add a request header to the page's own requests | No |
For a single API call, send it yourself from the DevTools console on the site's own tab, so cookies and origin are right:
const res = await fetch("/api/me", {
headers: { "Authorization": "Bearer eyJhbGciOi...", "X-Feature-Flag": "new-checkout" }
});
console.log(res.status, await res.json());
Or from a terminal: curl -H "Authorization: Bearer …" https://api.example.com/me. Neither affects the page's own requests.
To make the page itself send the header — every fetch, XHR, image and navigation — you need a rule in the browser that rewrites requests before they leave. Extensions do this through Chrome's declarativeNetRequest API. What to look for:
Set or remove any request or response header, for all sites, chosen domains or just this tab. It shows when a rule actually fired, works on fetch, XHR and POST, and has presets for User-Agent, no-cache, X-Forwarded-For and removing CSP or X-Frame-Options. Imports ModHeader exports. No account, no analytics.
Get HeaderForge for ChromeAccess-Control-Allow-Headers or the real request never goes. See CORS errors.More on this topic: HTTP headers list: the request and response headers that matter · Referer header: what it sends, why it's empty, and how to change it · Cache-Control header explained: max-age, no-cache, no-store and more · iframe "refused to connect": what causes it and how to fix it