HeaderForge

Practical HTTP header guide

Modify request and response headers in Chrome

Create precise HeaderForge rules for APIs, local development, QA, and browser testing while understanding where Chrome’s Manifest V3 network rules apply.

Quick start

  1. Select + Add header. The new row is enabled immediately, but stays inactive until you give it a valid header name. Untick the row’s checkbox to keep a rule without applying it.
  2. Choose Req for an outgoing request or Res for an incoming response.
  3. Choose Set, Append, or Remove.
  4. Enter the header name and, except for Remove, its value.
  5. Add a URL filter to limit the rule. A blank filter matches every permitted URL.
Scope sensitive values carefully

Use a narrow domain filter and short-lived test credentials for authorization headers, cookies, and internal feature flags.

Request and response headers

Request headers

Req changes a header before Chrome sends the request. Common uses include testing authorization values, feature flags, cookies, user agents, cache directives, and custom API headers.

Type:       Req
Operation:  Set
Header:     x-test-user
Value:      demo-user
URL filter: ||api.example.com/

Response headers

Res changes an eligible header while Chrome processes the server response. Use it to test MIME types, caching behavior, or application-visible custom response headers.

Type:       Res
Operation:  Set
Header:     content-type
Value:      text/html
URL filter: 127.0.0.1:8000

Set, Append, and Remove

Set

Creates or replaces the header value. Use Set for custom headers and whenever one authoritative value is expected, such as authorization, x-feature-flag, or content-type.

Append

Adds another value instead of replacing the current one. It is useful only for headers designed to carry multiple values, such as adding no-store to a response cache-control header.

Chrome restricts request Append to this exact lowercase allowlist:

  • accept
  • accept-encoding
  • accept-language
  • access-control-request-headers
  • cache-control
  • connection
  • content-language
  • cookie
  • forwarded
  • if-match
  • if-none-match
  • keep-alive
  • range
  • te
  • trailer
  • transfer-encoding
  • upgrade
  • user-agent
  • via
  • want-digest
  • x-forwarded-for

The allowlist is case-sensitive. See Chrome’s official Declarative Net Request header modification documentation.

Use Set for a custom request header such as x-test-user. HeaderForge marks unsupported request Append rules inactive so they cannot block valid rules.

Remove

Deletes the named header; its value field is ignored. Removing authorization, cookie, content-type, or caching headers can make an application fail, so target Remove rules carefully.

URL filter examples

HeaderForge uses Chrome Declarative Net Request urlFilter syntax. Prefer a domain-anchored pattern over a bare substring.

||api.example.com/        domain, subdomains, and paths
|https://api.example.com/ exact HTTPS URL prefix
api.example.com/v1/       substring match
127.0.0.1:8000            local development server
*                         every permitted URL

A bare filter such as api.example.com can also match that text in another URL’s path or query string. The domain anchor in ||api.example.com/ avoids that accidental match.

How response modification works

  1. A page starts a navigation, fetch, image load, or another network request.
  2. Chrome evaluates matching HeaderForge DNR rules.
  3. Request-header rules run before Chrome sends the request.
  4. The server returns a response.
  5. Response-header rules run while Chrome processes that response.
  6. Chrome delivers the processed response to the page or navigation.

DevTools Network can show the original response headers received on the wire. A response modification may therefore affect the application without appearing in that panel. Verify the application behavior or, where allowed, inspect the value with response.headers.get("header-name").

Security header limits

HeaderForge can request changes to eligible response headers, including names associated with CORS or content security policy. That does not make it a reliable security bypass.

  • Chrome’s network and Fetch security model enforces CORS.
  • CSP, X-Frame-Options, certificate validation, and mixed-content checks may be evaluated at stages a header rule cannot override.
  • Servers, caches, redirects, service workers, and other extensions can affect the final behavior.

Use HeaderForge for local development and authorized testing. For CORS or CSP testing, prefer an explicit development server, proxy, or test configuration.

Export and import rules

Export copies the current rules as JSON. Import accepts a JSON array and assigns fresh internal IDs, so rules can move between browser profiles without ID conflicts.

[
  {
    "enabled": true,
    "target": "request",
    "operation": "set",
    "name": "x-test-user",
    "value": "demo-user",
    "urlFilter": "||api.example.com/"
  }
]

Exported rules can contain credentials or other sensitive values. Review the JSON before storing or sharing it.

Test and troubleshoot a rule

  1. Confirm both the rule and the global HeaderForge switch are enabled.
  2. Compare the URL filter with the complete request URL.
  3. Reload without cache and account for redirects or service workers.
  4. Disable other header extensions temporarily to check for conflicts.
  5. Start with a custom request header on a local endpoint before testing protected browser behavior.

For concise answers about inactive rules, DevTools visibility, privacy, and supported browsers, read the HeaderForge FAQ. If your question is not covered, contact support.