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.

It's free — no in-app purchases, no subscription, and no account to register or sign into. There is no cloud service of its own: rules, credential variables and logs live only in chrome.storage.local on this machine.

Rules that use any advanced capability (header override, body override, response override, mock, delay, block, retry, method filter, query injection, sending cookies 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.

A hard boundary of the network layer, measured on Chrome 155: a pure URL rewrite that sends the request to a different origin arrives with Origin: null instead of your page's own origin, while a rewrite that stays inside the same origin is unaffected. Once the origin is null, a backend that allowlists by origin turns the request down even if it already allows your frontend domain, and the page sees net::ERR_FAILED. Two ways out: let the target environment allow any origin, or add an advanced capability (a response header override is the cheapest one) so the rule switches to background forwarding — that request is made by the extension itself, so page CORS never enters the picture.

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, keeps the previous numbers when the quota is exhausted and says the stats may lag. Background-channel hits are counted separately.

In this order: whether the popup's master switch is on (turning it off also uninstalls the network-layer rules) → whether that rule itself is enabled → whether the page has been reloaded, because requests already sent are never rewritten retroactively → paste the real request URL into the URL match tester to see whether a rule with a smaller priority number shadows it → if you use a regex, confirm it covers the whole URL: the network layer replaces the entire URL with the substitution, the background channel only the matched span, so a partial regex lands on two different results — the tester now puts both addresses on the screen and points at the step where they fork. Complex rules give you one more clue — when the background actually recorded that this page never received that config push, the popup reads “This page has not received the latest rules — reloading it usually fixes it” with a “Reload this page” button sitting to the right of that sentence (it appears only when the popup actually got that page back on this read, and pressing it does exactly what the browser's own reload does), and hovering names which of the two causes it is: the document predates an install, update or reload of the extension (reloading fixes it), or the extension is disabled for this site (re-enable it from Chrome's extension menu). It only says what it is sure of: non-http(s) pages, documents still loading and pages that never had this record stay silent. One more case is a page with no rule covering it at all: the popup's “create a rule for this page” then says up front which origins look blocked by CORS — those origins carry a “suspect” marker and sort first, and they come from the page's own failing native requests that no rule caught. A CORS block, an offline page and a DNS failure are the same shape, so it is a clue about what to build first, not a verdict. If you would rather ask all of it at once, the “Self-check” card in the popup's action grid (the options page also opens it at #self-check) puts five existing readings on one screen in this same order: the master switch, whether this host is inside the site scope, whether the background recorded that this page never received the last config push, which rule the page's address matches and which channel carries it, and whether the network-layer rules are actually installed in the browser. Each cell only restates a judgement already computed elsewhere; what it cannot read stays “unknown” and what has not landed yet stays “not yet”, instead of answering for the step above it.

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. Once the credential slots in a rule are written as a reference such as {{UAT_TOKEN}} with the real value kept under Settings → Credential Variables, neither the exported config nor a profile contains it at any point, so unticking share mode carries nothing out either.

Up to 200 rules, the last 500 request log entries, a 10 MB request body ceiling, the same 10 MB ceiling on the response body (over it the proxied request fails without truncation: fetch falls back to sending natively, while XHR does not fall back and fails with status 0), 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.

Fallback differs by channel. fetch falls back to the native request whenever interception or proxying fails (timeout, over-cap, a background error); XHR falls back only where proxying cannot deliver at all — a synchronous request or a non-string body — and on a failed hand-off it does not replay, it sets status to 0 and dispatches error, so a write is not executed twice; WebSocket is always opened natively, with the extension only rewriting the address. Synchronous XHR and non-string bodies have to fall back because proxying means a round trip through other contexts, which cannot deliver the "the result is ready when send() returns" contract — making it async would only hand the page an empty response. The single exception is a block rule: a blocked request is never replayed natively.

Click “Copy rule JSON” or “Download .json” in the preview panel, then open “Import / Export” in the extension's settings page and pick that file. Choose “Merge (keep existing, add new rules)” as the import mode, then confirm. Merge leaves your current rules alone and does not turn the master switch on for you, so if proxying is still off, switch it on from the popup. The file holds one rule — match type, match pattern and target URL — with no headers, query parameters or credentials.

No. A devServer proxy forwards site-relative paths such as /api, and the browser's request stays same-origin; the backend environment it points at lives in the devServer config and never appears in the URL the browser actually requests. Extension rules match on that request URL, so none of those entries would ever match a real address, and the file's shape is not the extension's import format either. Create a wildcard rule from the real API origin instead — for example https://fat-api.example.com/* to https://uat-api.example.com; the panel's “Fill the pattern from this URL” generates exactly that pattern.

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.