Net Tinker Help

Leer en español

I want to… — find the right tool

Every name in bold below is written exactly as it appears in the extension, so you can also find it with Ctrl+F here or search for it in the interface.

…change what a request or a response does

All of these are a rule. Pick the rule type from the Rule type dropdown when you create it.

…find my way around the extension

Your first rule: which fields actually matter

Press + New rule (in the popup or in the options page). The form opens on Mock the response (API), which is the most common case: answer a request from the browser instead of letting it reach the server. What the form shows up front is short — the rest is folded into four collapsible blocks, described below — and most of it is optional. Here is what a working JSON mock actually needs:

1. URL / pattern — the only field the extension refuses to save without. By default it is read as Contains, so /api/users is enough to catch every URL with that fragment. See Choosing which requests a rule matches.
2. Status code — starts at 200. The field is a plain number box with a list of suggestions attached (200, 201, 204, 301, 400, 401, 403, 404, 429, 500, 502, 503…): click it to pick one, or just type any code you want.
3. Headers — a new mock rule opens with Content-Type: application/json already written in the box, as a real value you can edit or delete: what is in the box is what gets saved. Delete it and the mock comes back as plain text — a legitimate choice, and nothing writes the header back when you save. Opening a rule that already exists never adds it, even when its headers are empty.
4. Response body — what the caller gets. The { } Format and { } Minify buttons above the box tidy up JSON, and a note underneath tells you whether what you typed parses as JSON at all.

Everything else narrows the rule down or helps you find it later, and lives in four collapsible blocks: Organization (description, tags, group), Advanced matching (source, match type, method), Additional conditions (optional) (header, body and initiator conditions) and Network simulation (latency and status code, which apply to every rule type). A new rule opens with the four of them closed; editing an existing one opens each block that rule actually uses, so a folded block never hides something you set. Two things worth doing before you close the form:

• Paste a real URL into Test URL (optional). It tells you straight away whether this rule would match it, without saving anything or making any request.
• Save, reload the page, and look at the extension's toolbar icon: it shows a count of rules applied on that tab. If it stays empty, the rule never fired — go to Why a rule might not be firing.

Rule types

Every rule has exactly one type, which decides what happens once it matches a request. The name in bold is the one in the Rule type dropdown, where the nine of them are grouped by what they do to the request — Mock, Modified passthrough, Redirect and Block, the split described in Mock vs. modify & passthrough. The shorter name in brackets is how the same type is labelled in the rule list, the type filter and the captures list. One rule does one of these things — but a request can be governed by several rules at once, so combining two types is a matter of writing two rules. See When several rules match the same request.

Latency is not a rule type

Delaying a request used to be a type of its own, and it no longer is. Latency (ms) lives in the Network simulation block of the rule form and applies to every type: a mock arrives late, a redirect leaves late, a blocked request fails late. Leave the field empty and the rule adds no latency at all; 0 is not the same thing as empty — it is a real, if tiny, wait.

If all you want is to slow an endpoint down, use the No change (delay only) type and give it a latency. Rules that used to be of the old Delay type were converted to exactly that, keeping their milliseconds, the first time you ran this version.

Overriding the status of a real response

There are two fields in the form that hold an HTTP status code, and they are not the same thing. It is the easiest confusion to fall into here, so it goes first:

The case it exists for: you want to see what your error handling does with a 500 from that endpoint, but with the real data. With a mock you would have to hand-write the whole body — and then you would no longer be testing against the real response, which is exactly what you wanted to keep.

• 200 to 599 is what's accepted. Outside that range the browser cannot build the response at all, so an out-of-range value is ignored rather than breaking the request.
• The status text is left empty. A 500 still carrying the original response's OK contradicts itself the moment you log it; and an empty status text is what the browser already hands you over HTTP/2 and HTTP/3, which have no reason phrase.
• With 204, 205 or 304 the body is dropped, because those statuses cannot carry one. That is exactly what the browser does with a real response of that kind.
• Leave the field empty to keep the real status: that is the only way to remove an override.
• On a rule that mocks or blocks the request it does nothing, and that is not a bug: there is no real response to override there. In the Activity panel such a rule shows up as matched but not applied. For a mock, the field that counts is Status code.

And like any modifier, it combines: a single rule can override the status and transform the response body, and change a header on it, and arrive late.

Mock vs. modify & passthrough

This is the single most common point of confusion, so it's worth spelling out on its own:

A practical way to tell them apart while debugging: open DevTools' Network tab. A mocked request never shows up there at all (it never reached the network); a modified-and-passed-through one does, with the rewritten URL/body/headers. The captures list says the same thing in words, per request: "reached the network" or "never reached the network".

This is a property of the request, not of each rule taken alone: as soon as one matching rule mocks it, the request never leaves the browser, whatever the other matching rules do. A mock with a latency is a delayed answer that still never reaches the server — see When several rules match the same request.

Choosing which requests a rule matches

Whatever its type, a rule always starts from one pattern: the Source dropdown decides whether that pattern is compared against the full URL or only the Host, and the Match type dropdown decides how. Both live inside the form's Advanced matching block, which is folded away until you open it:

Rather than guessing, paste a real URL into Test URL (optional), the box right under the pattern. It answers ✓ Matches or ✗ Doesn't match as you type, tells you what it compared against (the whole URL or just the host), and warns you if a Regex pattern doesn't compile. Nothing is saved and no request is made. It only checks the pattern, the match type, the source and the exclusions — not the method or the header/body/initiator conditions below.

Everything under /api/ except the health check

A pattern that is broad enough to be useful is usually broad enough to catch something you didn't want: the health check your dashboard polls every five seconds, the login call, the one request that already carries a real token. That's what Except URLs containing (one per line) is for — it sits just under the three dropdowns in Advanced matching. Write one pattern per line; if any of them appears in the request's URL, the rule leaves that request alone.

Two things about this box are deliberate, and worth knowing before you fight it:

• It is always compared against the whole URL, even when Source is set to Host. That's what makes it usable on the rules that need it most: a rule scoped to a host would otherwise have nothing but a hostname to compare against, and /api/health never appears in one. It also means you can exclude a whole subdomain here (static.example.com) as easily as a path.
• It is always plain text, whatever Match type says. No regex, no wildcards: a . is a dot and a * is an asterisk. Case matters, as everywhere else. If you genuinely need a regular expression to describe what to leave out, the old escape hatch still works — a negative lookahead in the pattern itself, ^(?!.*health).*api.* in Regex mode.

The Test URL box knows about exclusions: an excluded URL answers ✗ Excluded by “…” and names the line responsible, instead of claiming a match that would never happen.

On top of the pattern, a rule can carry extra conditions, under Additional conditions (optional) in the form — except Method, which sits with the other two dropdowns under Advanced matching. They are all optional, and all of them have to hold at once (AND, never OR):

• Method — anything other than "Any" restricts the rule to that verb.
• Header condition (optional) — a header name plus is present / is absent / equals / contains / matches regex.
• Body condition — Contains / Equals / Regex against the outgoing request body. (Wildcards are offered for the URL and initiator patterns, but not here.)
• Initiator domain (optional) — the host of the page making the request, not the request's target, with the same four match types as the URL pattern.
• Pinned to a tab (📌 in the popup) — the rule only applies to requests coming from that one tab.

When several rules match the same request

Nothing stops two rules from matching the same request, and when that happens all of them apply — not just the first one. That is what lets you redirect a call and add a header to it, without trying to cram both into a single rule.

They are applied in list order, from top to bottom, and each rule only has a say in the part of the request its own type is about: a headers rule contributes header changes, a mock contributes the answer, and any of them can contribute a latency on top. When two rules speak about the same thing, the one lower in the list wins. So the order of the rule list is the priority — use the ↑ and ↓ buttons on a rule to move it above or below another one, and what your request ends up doing really does change.

Two combinations are settled by a rule of their own rather than by list order:

• Blocking always wins. If any of the matching rules is a Block the request, the request fails — wherever that rule sits in the list, and whatever the other rules say. A block plus a mock is a failed request, never a mocked one; if a latency is in play too, the failure simply arrives late. That is the answer to "I have a rule that blocks and a rule that answers, why does it fail?": move the block out of the way (disable it, or narrow its pattern) if you want the mock.
• Nothing that acts on the way back applies to a mock. A mocked request never reaches the network, so there is no real response for a Modify the real response body rule — or for the response-header side of a Modify headers rule — to work on, even when it matched the same request. Write what you want directly into the mock's own body and headers instead.

To see which rules governed a given request rather than reasoning it out, record the tab and open the captures list: a request that matched three rules gets a ⚡ line for each of them, and the toolbar badge counts rules applied, not requests.

Using variables

Define a name/value pair once (the "{{ }} Variables" button in the options page) and reuse it as {{name}} anywhere you'd otherwise retype the same string: a rule's body, a header's value, a redirect URL, a query param's value, the replacement text of a "Replace text in the URL" rule, and both the replacement text and the new JSON field value of a "Modify the real response body" rule.

A name that doesn't match any defined variable is left exactly as written — {{typo}} shows up literally in the request or response, rather than silently disappearing, so a mistake is obvious instead of a mystery. Variables are not substituted into a rule's matching fields (the URL pattern, or a header/body/initiator condition) — those compare against the real, live request, so a variable there wouldn't mean anything.

Environments

An environment (the "🌐 Environments" button, next to Variables) is a named set of overrides on top of your variables — Local, Staging, Prod, whatever you need. It only has to override what actually changes between environments; anything it doesn't mention keeps the variable's own base value.

Pick the active environment from the star button next to it in the options page, or from the Environment dropdown in the popup (only shown once at least one environment exists). With no active environment, every variable simply uses its own base value — exactly like before environments existed.

Why a rule might not be firing

First, a quick check that saves a lot of time: the extension's toolbar icon carries a badge with the number of rules applied on the current tab. If it's empty after reloading, nothing matched at all and the list below is where to look. If it's counting, the rule is firing and the surprise is in what it does, not in whether it runs.

Check these in order — they cover every reason a rule can silently fail to apply:

1. The master toggle (On at the top of the popup, Extension enabled in the options page) is off. Nothing applies at all while it is.
2. The rule's own enable/disable toggle is off.
3. The rule belongs to a group that's disabled. A disabled group silently disables every rule inside it — in the rule list, those rules show a ⚠ next to the group's name.
4. The rule is pinned to a specific tab (📌) and you're testing from a different one.
5. This site is outside the configured scope. This is the most misleading one, because it has nothing to do with the rule: if Scope (options page) is set to "Only localhost" or "Only these domains", then on every other site no rule applies at all. The toolbar icon says so — hover it and you'll read "out of scope here" — and in that mode the popup warns too. Watch out for the empty-list case: "Only these domains" with no domain listed allows nothing, anywhere.
6. The request's HTTP method doesn't match the rule's configured Method (if it's not set to "Any").
7. The URL/host pattern doesn't actually match — check the match type as well as the pattern itself, and paste the real URL into Test URL (optional) to settle it. If the match type is Regex, a typo that makes the pattern invalid means the rule matches nothing rather than throwing an error — the test box flags that case explicitly. Another common one: writing * or ? in a pattern still set to "Contains" or "Equals", where they are just literal characters — those only mean anything in Wildcard mode.
8. The rule has an exclusion pattern that matches this URL. It's the easiest one to overlook, because the positive pattern does match and everything looks right: check Except URLs containing inside Advanced matching — the block opens by itself when the rule has any, and the folded summary says how many. Pasting the URL into Test URL (optional) settles it instantly: it names the line that excludes it.
9. There's a Header condition, Body condition or Initiator domain attached to the rule, and the current request doesn't satisfy it. For header and body conditions on XHR requests specifically: a redirect/query-param/ replace-in-URL rule can never fire based on either, because the URL is decided before the page has set its headers or called send(body) — this only works for the "mock", "block", "no change", "modify request body" and "modify headers" rule types on XHR (it works for every rule type on fetch). A body condition also only ever matches plain text (JSON, form-encoded, plain strings) — FormData/Blob/binary bodies are never read for it.
10. The request isn't fetch or XMLHttpRequest. Net Tinker can only intercept those two — it cannot affect <img>, <script src>, CSS, fonts, or any other resource type when it comes to applying a rule (the DevTools capture panel can still see all of those, it just can't act on them).
11. The request never happened, because the browser answered it from its own cache. There is nothing to intercept, and it looks exactly like a rule that doesn't work. Use ↻ Reload without cache in the popup to reload that tab ignoring the cache, or add a Modify headers rule with the Cache bypass preset so it happens on every reload.
12. Another matching rule is overruling it. Rules don't shadow each other — they all apply — but where two of them speak about the same thing, the one lower in the list wins, and a Block the request rule beats everything. So the rule can be firing perfectly and still leave no trace: reorder the list, or narrow the other rule's pattern. See When several rules match the same request.
13. The rule has a type this version doesn't know how to apply. It can happen after importing a file written by a newer version, or if an update left a rule half-migrated. That rule alone is skipped, exactly as if it hadn't matched — never answered with an empty mock, and any other rule that matched the same request still applies — and the row is flagged in the captures list with ⚠ plus the unrecognised type name, so the situation is visible instead of looking like ordinary traffic. Reopen the rule and pick a type again.
14. A Modify the real response body rule matched, but the response was a live stream it can't buffer, so it was deliberately left alone. See Things that look like bugs but aren't; the captures list says "matched but not applied — streaming response" for exactly this.
15. You have two copies of Net Tinker installed at once — typically the Web Store one plus an unpacked development build. Both patch the same page, and whichever answers first takes the request, so the other copy sees nothing: no badge, no line in the captures list, and the rule you are looking at appears to do nothing even though a rule did run. The giveaway is that the request clearly was intercepted while the extension you're watching shows no activity at all. Disable one of the two.

Seeing what actually happened

Guessing whether a rule ran is the slow way. There are three places that tell you, each answering a different question:

• The toolbar badge — a live count of how many rules have been applied on the current tab. Costs nothing to look at and answers "is anything happening at all?".
• The captures list — a stored log of requests, with the rule (or rules) that matched each one. This is the one to open when something is wrong.
• The DevTools panel — live traffic while you work, and the place to build rules from it. See Building rules from real traffic.

The captures list is off until you ask for it. Open the popup on the tab you want to watch and switch on Record this tab — only that tab's requests are captured. Then open the list with 📡 Captures in the options page (or View captures in the popup), which shows the Captured requests panel.

Each row tells you, in this order: the page, the status, the time, and then what Net Tinker did with it.

• A ⚡ plus a rule name means that request matched that rule. Tick Applied only to hide everything else, and use the search box to narrow by URL or rule name. When several rules governed the same request each one gets its own ⚡ line, so the same URL appearing more than once is the list telling you exactly which rules took part.
• Every matched row also says reached the network or never reached the network, which is the quickest way to confirm a mock really is a mock.
• A ⚠ means the rule matched but could not be applied — an unrecognised rule type, or a streaming response a "Modify the real response body" rule had to leave alone. Both are explained in Why a rule might not be firing.
• View rule opens the rule that was applied; Disable this rule switches it off from here; + Rule builds a new rule from that request; and clicking the row opens the full Request detail, including the headers and what exactly was changed.

Unlike the DevTools panel, these captures are stored, so they're still there after you close the tab or the browser. The list keeps the 200 most recent and Clear empties it. Recording stops on its own if you close the tab being recorded.

Things that look like bugs but aren't

Net Tinker works by patching fetch/XMLHttpRequest inside the page's own JavaScript. That approach has a few unavoidable side effects:

• Adding a request header can trigger a CORS error. If the added header isn't allowed by the server's CORS policy on a cross-origin call, the browser blocks the request — this happens at the browser's CORS layer, underneath anything Net Tinker can control.
• The "Development CORS" preset does not lift a real CORS block. The browser runs its CORS check on the response the server actually sent, before Net Tinker gets to touch the response headers. The permissive values the preset writes are only ever seen by the page's own code. It is useful for testing how your code behaves with those headers; it is not a way around a server that doesn't send them.
• Response headers added by a rule don't show up in DevTools' Network tab. The Network tab shows the real bytes that came over the wire; a "Modify headers" rule's response-side changes are applied afterwards, only to the object the page's own JavaScript reads. They're real to the page — just invisible to that particular DevTools view.
• DevTools' "Initiator" column shows interceptor.js for every request while any rule is active on the page, because every request passes through Net Tinker's patched fetch/XMLHttpRequest before reaching (or not reaching) the network. It doesn't affect behavior, only attribution. If it bothers you, add interceptor.js to DevTools' own Ignore List (Settings → Ignore List) — DevTools then skips those frames when computing the initiator.
• A rule pinned to a tab you have since closed never fires again. A tab id means nothing once that tab is gone, so the rule stays inert forever — and reopening the same page gives you a new tab with a new id, which doesn't bring it back. You don't need the original tab: the options page shows a 📌 marker on those rules and a 📌✕ button that removes the restriction.
• A "Modify the real response body" rule does nothing on an XHR whose responseType is binary. The body can only be transformed when responseType is "", "text" or "json"; with "blob", "arraybuffer" or "document" there is no way to read it as text, so that particular request comes back untouched. The rule itself is fine — it just can't act there.
• "Overwrite a JSON field" leaves a non-JSON body completely alone. Same if the dot path doesn't lead to an object (say user.status when user is a string). The body is returned exactly as it arrived, rather than being half-rewritten or replaced by a guess. Use the "Find and replace" mode for bodies that aren't JSON.
• "Modify the real response body" skips responses that are open-ended streams. Transforming a body means reading all of it first, and a media type whose whole contract is to stay open — text/event-stream (server-sent events), multipart/x-mixed-replace — never finishes. Those responses are handed back untouched, with the stream intact, and the rule simply doesn't apply to that request; the captures list records it as "matched but not applied — streaming response" so it isn't a silent no-op. The criterion is the media type, not the size: an ordinary large response does finish, so it is transformed normally — it just arrives in one piece instead of progressively. Rules of every other type leave the response body untouched and have neither effect.

Building rules from real traffic

Open DevTools on any page and look for the "Net Tinker" panel (next to Elements, Console, Network, etc.). It lists every request the page makes while the panel is open — not just fetch/XHR, every resource type — so you can find the exact call you want to work with. The header shows Recording, and clicking it switches to Paused if you'd rather freeze the list; tick Preserve log to keep entries across navigations, and Clear empties it.

1. Each row has a "+ Rule…" dropdown plus a dedicated Mock button. Picking a type opens the rule editor pre-filled with that request's real URL (as an Equals match, so it only affects that exact call) and its method. The dropdown offers every rule type except the mock, which has its own button.
2. A rule built this way arrives disabled unless it's a mock or a block — those two are complete the moment they're created, while the rest are still empty skeletons, and enabling an empty "redirect" or "response body" rule would break the very endpoint you're debugging. Fill it in, then switch it on. The panel says which of the two happened each time.
3. Mock goes further: it also copies the request's real status code, response headers and response body into the new rule, so you start from what the server actually returned instead of typing a fixture by hand.
4. A ⚡ mark next to a row means one of your currently-enabled rules would intercept that exact request — evaluated live against your current rules, not against whatever was active when the request actually happened.
5. Each row also has a "Copy as…" option to copy the request as a cURL command or a fetch() snippet, for pasting into a terminal or the console.
6. Export HAR saves the requests currently visible in the list as a standard .har file, for handing to someone else or loading into another tool. The dialog lists the sensitive values it found and offers Redact credentials (always on when the dialog opens) and Include response bodies (always off, capped at 1 MB each, because bodies are what makes the file heavy). Both boxes are reset every time it opens, so the safe option is never left off from a previous export. A HAR carries real request headers, Authorization included, plus cookies — treat the file like a credential.
7. For a GraphQL request (detected automatically and shown as its operation name next to the URL), creating a rule from it also fills in a Body condition requiring that operation's name — because a GraphQL endpoint serves every operation at the same URL, a rule matched on URL alone would otherwise apply to all of them. You can see and edit this in the opened rule (it's just the same body condition described above, pre-filled for you). The panel's filter box also searches by operation name.
8. The panel lists every resource type, but rules can only be applied to fetch/XHR. Build one from an image, a script or a stylesheet row and the panel warns you: the rule is created, but it will never fire. The "fetch/XHR only" checkbox hides those rows if you'd rather not see them.

Captures shown in this panel live only in memory while DevTools is open — closing DevTools clears them, and nothing is written to storage until you explicitly turn a captured request into a rule or export a HAR. That is the difference from the captures list in the options page, which is stored on purpose.

What "sanitize on export" does (and doesn't) cover

Export writes your rules and groups to a JSON file, together with your variables and environments. Exporting everything includes every variable you have; exporting a selection of rules only includes the variables those rules actually reference by name, and prunes each environment down to the same set. Which environment is currently active is a local preference and is never part of the file.

Because that file gets shared, the export goes through a dialog first. It lists what it found that looks like a credential, and ticks Replace credentials with __REDACTED__ for you when there is anything to hide. Sanitizing looks for names that suggest a credential — anything containing auth, token, secret, password, passwd, apikey, api_key, api-key, credential, signature, cookie or session — and replaces the matching value with __REDACTED__. It checks:

• Header names, both in a mock's headers and in the request/response header operations of a "Modify headers" rule.
• Query parameter names of a "Query parameter" rule.
• Field names anywhere inside a JSON body, at any depth.
• The query string of the rule's own URL pattern and of a redirect URL — but only the query string. A path segment could be anything, so guessing there would mangle legitimate URLs. A pattern whose match type is Regex is skipped entirely, because splitting a regex on ? would corrupt it.
• Variable names — {{token}}, {{apiKey}} and friends are the likeliest secret in the whole file. An environment's overrides are judged by the name of the variable they point at, so a "Prod" override of token is redacted exactly like the variable itself.

It deliberately does not touch:

• Non-JSON request/response bodies (plain text, XML, form-encoded, etc.) — there's no reliable way to tell a token apart from ordinary text in an arbitrary format, and guessing wrong would silently corrupt the body. Only bodies that parse as JSON are inspected, and the dialog names the bodies it could not check so you can review them yourself.
• A value under a field name that doesn't look sensitive — a bearer token stored under a field literally named value or data would not be caught, because the check is name-based, not content-based.
• Booleans, or the literal strings "true"/"false", even under a sensitive-looking name. A flag is not a secret, and redacting it would just produce a broken rule.
• Two header names that look sensitive but never carry one, whatever their value: access-control-allow-credentials (a fixed CORS flag) and www-authenticate (the challenge that makes a mocked 401 realistic).
• The fields of a "Modify the real response body" rule — the text you search for and replace, and the JSON field value you write. Those are exported as you typed them, so don't park a token in there before sharing a file.
• The rule's own name, description and tags — those are yours to write, so nothing there is scanned.

Treat sanitize-on-export as a safety net against the most common accidental leak, not as a guarantee that an exported file contains no secrets — review what you're sharing before you send it.

On the way back in, Import lets you pick what to bring over and warns you when a rule already exists (same type, method and pattern), offering to import it as a copy, skip it or overwrite the existing one — with the same choice, separately, for variables whose value differs from yours.