Point a FAT frontend at a UAT backend — one rule, no code changes

It intercepts the API requests a page makes and sends them somewhere else. In development that usually means pointing a frontend running against one backend at a different environment, so you can test UAT code from a FAT page without editing the app or redeploying.

The page interceptor patches fetch, XMLHttpRequest and WebSocket in the page's main world, and relative URLs are resolved to absolute ones before matching. Rules that only rewrite the URL are compiled into declarativeNetRequest redirects, which the browser applies to matching requests of every resource type: main and sub frames, XHR, scripts, stylesheets, images, fonts, media and other.

Wildcard treats * as any text and appends whatever the trailing * captured to the target URL. Prefix matches the beginning of the URL and appends the remaining part. Regex must cover the whole URL: the background channel replaces only the part the pattern matched, while the network layer replaces the URL entirely, so anchor the pattern with ^ and capture the tail with (.*)$ if you want both channels to agree. When several rules match, the lowest priority number wins; ties keep the order shown in the rule table, so give each rule its own number.

It is injected on all http and https pages, and rules match on request URL, so it works on internal tools, localhost dev servers and staging domains alike. It does not run on chrome:// pages, the Chrome Web Store, or other extension pages, which Chrome restricts for every extension.

Rules that use any advanced capability (header override, body override, response override, mock, delay, block, retry, method filter, query injection or WebSocket) are executed by the extension's background context, which holds host permissions, and the page receives a response the extension constructed — so page CORS checks do not apply. A pure URL rewrite is handled as a network-layer redirect instead, where the browser still validates Access-Control-Allow-Origin on the redirected response. If a target environment does not allow your origin, add any advanced capability (a response header override is the cheapest) and the rule switches to the background channel.

Because the network layer cannot express what you asked for. A wildcard that does not end in *, an empty target URL, or any advanced capability is routed to the background channel on purpose, since compiling it anyway would silently change the redirect result. The URL match tester shows the channel for any URL before you rely on it.

Rules that only rewrite the URL cost no JavaScript per request — the browser resolves them in its network stack. Background-channel requests add one extension hop plus whatever delay you configure, and each proxied request has a 30 second ceiling. User regexes are checked for nested-quantifier ReDoS patterns before use, and regular expressions heading for the network layer are validated against Chrome's RE2 engine first, because one unsupported pattern would make the whole batch of rules fail to install.

Network-layer redirects never reach the extension, so there is nothing to log per request. Their rule-level hit counts appear under DNR hits for the last five minutes; the quota Chrome allows for that read is limited, so the panel refreshes on demand and quietly keeps the previous numbers when the quota is exhausted. Background-channel hits are counted separately.

One rule can carry a list of conditions — a URL pattern, an HTTP method and query parameters — and the first matching condition decides the body, status code and content type, falling back to the rule's default body when none match. That lets a single mock stand in for several endpoints, or for several states of one endpoint. Mocked requests never touch the network, and returned status codes are clamped to 200–599.

A block rule makes the request fail the way a network failure does, which is what exercises offline and retry handling. Overriding the response status instead gives you a real HTTP error code, status text and headers, which is what exercises error rendering that depends on the code. Blocked requests are never replayed by the native fallback — otherwise the extension would send exactly the request you asked to suppress.

Retrying sits behind a per-rule switch and runs on the background channel. Switched on, a rule makes 1 to 5 extra attempts after the first, spaced by an interval you set between 100 and 30000 ms (default 1000). An attempt is retried when it throws — including the 30 second per-attempt timeout — or when it returns a 5xx status while attempts remain; the last response or error reaches the page once the budget is exhausted. Because retrying is a background-channel capability, a rule that uses it never becomes a network-layer redirect.

Yes. Export the full configuration as JSON — share mode is on by default, stripping Authorization, Cookie and similar request/response headers plus token-like query parameters, untick it for a verbatim local backup — and teammates import it either as a replacement or merged into what they already have. Export captured traffic as a HAR 1.2 file, or import a HAR recorded elsewhere to create rules automatically. Anyone can paste a cURL command — DevTools “Copy as cURL” output — to prefill a rule. Environment profiles store a named snapshot of the whole rule set.

Up to 200 rules, the last 500 request log entries, a 10 MB request body ceiling, delays between 0 and 60000 ms, retry off by default and then 1 to 5 extra attempts at 100–30000 ms, a 30 second ceiling per proxied request, and response status codes clamped to 200–599 so the page can always construct a valid Response object.

The page falls back to the browser's native fetch, XMLHttpRequest or WebSocket, so the request goes out as it normally would. Non-string bodies such as FormData, Blob and ArrayBuffer cannot cross the message boundary and also fall back to native. The single exception is a block rule: a blocked request is never replayed natively.

No. Rules, logs, profiles and preferences live in chrome.storage.local on your machine. The extension contains no analytics, no telemetry and no remote service of its own; the only network traffic is the API traffic you ask it to proxy. Note that the request log records the headers and bodies it proxies — including any tokens — locally, which is worth remembering before you share an exported HAR or a copied cURL command.

It is built and tested against Chrome (Manifest V3). Edge runs Chromium extensions, so the same build normally works there; Firefox's Manifest V3 support differs around declarativeNetRequest, so it is not a supported target today.