How to Switch Between API Environments in Chrome (Dev, Staging, Prod) — HeaderSnap ModHeader was removed from Chrome & Edge over a hidden data collector — what happened and what to do
HeaderSnap
April 11, 2026

How to Switch Between API Environments in Chrome (Dev, Staging, Prod)

Switching between dev, staging, and production while doing API work in the browser usually involves one of these:

  • Editing code to swap endpoints or auth tokens before each test run
  • Keeping multiple browser windows open with separate logins
  • Maintaining a mental note mapping each environment to its current token

None of these scale well. When you’re tracking down a bug that only reproduces in staging, or validating a fix against production config, the overhead of environment context-switching breaks the debugging flow.

There’s a cleaner approach: HeaderSnap profiles. One profile per environment, one click to switch. Rules stay isolated per environment — no staging tokens leaking into production requests, no manual cleanup between context switches.


Why manual environment switching is slow

Most API auth tokens are environment-specific. The staging Authorization: Bearer <token> is invalid against the production API and vice versa. When you’re debugging across environments, you’re constantly swapping these — either in your app’s code or in whatever tool is managing headers.

If you’re injecting headers at the application layer, you’re editing source files between test runs. If you’re using Chrome DevTools, there’s no persistent header injection — it resets with every reload. If you’re using a flat-list header extension, you’re toggling individual rules on and off and hoping you remember which ones belong to which environment.

HeaderSnap’s profile system handles this by treating each environment as an independent context with its own set of rules. Only the active profile’s rules fire.


Setting up one profile per environment

Open HeaderSnap. The profile bar runs across the top — you start with a Default profile. Add two more: Staging and Production.

Click + New Profile — it creates a new profile with a default name. Click the pencil icon on the new tab to rename it “Staging”. Do the same for “Production”. You now have three named contexts. Rules you add to each profile only activate when that profile is selected.

Add auth rules to each profile:

Click the Staging tab to activate it. Add a rule:

  • Header name: Authorization
  • Header value: Bearer <your-staging-token>
  • URL pattern: api.staging.yourapp.com/*
  • Action: Set

Switch to the Production tab and add the equivalent rule: same structure, production token, production API domain.

Leave Default empty — it becomes your “no overrides” state for when you want clean baseline requests with no injection active.


Switching environments takes one click

When you need to work against staging: click the Staging tab in the HeaderSnap popup. All rules in that profile activate immediately. The production token goes dormant — it’s stored but not registered with Chrome’s network layer.

Switch to Production: click the tab. The staging rules stop firing, the production rules become active.

The switch is immediate. HeaderSnap uses Chrome’s declarativeNetRequest API to update the active rule set. There’s no request interception, no per-request latency, no persistent service worker intercepting traffic. Chrome’s DNR fires the rules natively. Click, switch, continue working.

No code changes. No browser restart. No environment variables to update.


More than auth tokens

The profile system works for any header that varies by environment.

Feature flags. If your backend reads a custom header to enable staging-only features — X-Feature-Flag: new-checkout-flow — put that rule in your Staging profile. It won’t fire when Production is active.

Internal testing markers. QA teams often send headers that bypass rate limits or trigger test modes: X-Internal-QA: true. A dedicated QA profile keeps these scoped so they never reach production.

Response header overrides. HeaderSnap modifies response headers too. If you’re overriding Access-Control-Allow-Origin to test CORS behavior against your staging API, scope that rule to your Staging profile — it won’t affect production responses.


One thing to get right: URL pattern scoping

When you add auth header rules, scope the URL patterns tightly. A loose pattern like * attaches your token to every request your browser makes — analytics, CDN assets, third-party API calls.

Use domain-specific patterns:

  • api.yourapp.com/* — production API
  • api.staging.yourapp.com/* — staging API
  • localhost:3000/* — local dev server

HeaderSnap supports both glob patterns (wildcards with *) and full regex for more complex matching. If you need to match several API paths without creating separate rules, a regex like ^https://api\.(staging\.)?yourapp\.com/ covers both staging and production with one pattern.


The practical result

Set up three profiles once and environment switching stops being something you think about. Switching context — including switching back to “no overrides” — takes less time than finding the right config file.

HeaderSnap is a free Chrome extension with no analytics, no data collection, and no account required. All features — unlimited profiles, export and import — are included at no cost. No paid tier, no locked features.

HeaderSnap