Header Profiles for Multi-Environment Development — Staging, QA, Production — HeaderSnap ModHeader was removed from Chrome & Edge over a hidden data collector — what happened and what to do
HeaderSnap
← All posts
March 17, 2026

Header Profiles for Multi-Environment Development (Staging, QA, Production)

If you’re working across staging, QA, and production environments, you’re probably managing different auth tokens, API keys, or internal flags depending on which environment you’re hitting. Most developers handle this the hard way: disable headers manually, remember which values go where, or keep multiple browser profiles open just to keep environments isolated.

There’s a cleaner way. HeaderSnap’s profiles feature lets you maintain a separate set of header rules for each environment and switch between them with one click.

What header profiles actually solve

The problem isn’t just convenience. When you’re mid-debugging, context-switching between environments means disabling and re-enabling individual rules, or swapping header values one by one. Mistakes creep in: you forget to re-enable a rule before testing, or you accidentally send a staging token to a production endpoint.

Header profiles solve this by grouping your rules by context. Each profile holds its own independent set of rules. Switching profiles activates exactly the rules you want for that environment — instantly, and without touching anything else.

Setting up three profiles: Staging, QA, Production

Here’s a practical walkthrough. Assume you’re working on an app with three environments, each requiring a different bearer token for API calls.

Step 1: Create your profiles

When you install HeaderSnap, you start with a single Default profile. Open the extension popup — the profile bar sits at the top. Click + New Profile to add your first environment profile.

HeaderSnap auto-names new profiles (“Profile 2”, “Profile 3”), but you can rename them immediately: click the ✎ icon on the profile tab and type the name you want. Create three profiles named Staging, QA, and Production.

You can rename any profile at any time by clicking its ✎ icon. The Default profile stays around as a fallback but doesn’t need to hold any rules.

Step 2: Add rules to each profile

Click the Staging tab to make it active, then add a rule:

  • Label (optional): Staging Auth
  • Header name: Authorization
  • Header value: Bearer <your-staging-token>
  • URL pattern: api.staging.yourapp.com/* (glob) or a regex pattern like .*\.staging\.yourapp\.com.*
  • Action: Set
  • Header Target: Request

Repeat for QA and Production, using the corresponding token and URL pattern for each. Because rules belong to the active profile, the rules you create while Staging is active are stored under Staging — they won’t fire when QA or Production is active.

Step 3: Switch with one click

When you need to test against staging, click the Staging tab. HeaderSnap immediately activates only the rules in that profile. Click Production and production rules become active — staging rules go dormant without being deleted.

No re-entering values. No disabling individual rules. Just click the profile you need.

More than auth tokens

Profiles work for anything you’d scope to an environment:

Feature flags via custom headers. If your backend reads a custom header to enable experimental features in staging — something like X-Feature-Flag: enable-new-checkout — add that rule to your Staging profile only. It won’t leak into production requests.

Internal testing headers. QA teams often send internal markers that bypass rate limits or trigger test modes (X-Internal-QA: true). A QA profile keeps those scoped to QA testing sessions.

Response header overrides. HeaderSnap can modify response headers too. If you’re testing CORS behavior by overriding Access-Control-Allow-Origin on a staging API, put that rule in your Staging profile — it won’t affect production responses.

How it works under the hood

When you switch profiles, HeaderSnap updates Chrome’s declarativeNetRequest rules to reflect only the enabled rules in the active profile. The switch is near-instant because it’s updating a rule set, not intercepting requests on the fly.

Rules in inactive profiles are stored but not registered with Chrome’s network layer — they’re dormant until you activate that profile again. Nothing leaks across profiles.

Keeping profiles clean

A few habits that make multi-environment header management less messy:

  • Name rules clearly. Since rules display in a list, descriptive names (“Staging Auth Token”, “QA Feature Flag”) are worth the extra characters.
  • Keep Default empty. Treat Default as your “no overrides” state — useful when you want to test with no header modifications active.
  • Delete profiles you’re done with. When you delete a profile, any rules assigned to it automatically move to Default rather than being lost. From there you can clean them up deliberately.

The alternative

Without profiles, the options are: manage one big rule list and enable/disable manually, keep multiple Chrome user profiles for different environments, or use browser bookmarks to remember which tokens go where. None of these scale well when you’re doing active multi-environment development.

Profiles make the context switch explicit and instant. One click tells the extension exactly which environment you’re working in — nothing more to manage.

If you’re regularly testing across multiple environments, set up your profiles once and you won’t think about header management again.