Net Tinker: Mock & Modify API Responses

Mock, redirect, delay or rewrite HTTP requests from the browser. No backend, no account, everything stays on your machine.

Net Tinker does one thing: it lets you decide what an API answers while you are working on the page that calls it — without touching your backend, without an account, and without anything leaving your machine. Everything in it is that one idea. A rule says which requests to catch and what to do with them. Scenarios organise rules. The importers write rules for you. The network-simulation fields are settings on a rule. There is nothing else to learn. WHAT A RULE CAN DO • Mock a response — return your own status, headers and body. The request never reaches the network. • Change the real response — find and replace text in it, or overwrite a single JSON field and leave everything else exactly as the server sent it. • Modify a real request — change its headers or its query parameters, replace its body, or overwrite a single JSON field of that body by its dotted path and leave the rest exactly as the page built it. Then let it go out as usual. • Redirect a request to a different URL, or rewrite part of the URL. • Block a request entirely. • Override the status code the real response came back with. • Add latency to any of the above, to see how your UI behaves on a slow connection. Mocking an endpoint and slowing it down is one rule, not a choice between two. • Write one of your variables from the response, so the requests that follow can use what this one returned. The last three are modifiers rather than rule types: any rule can carry them, and you never have to give up one behaviour to get another. MAKE THE NETWORK MISBEHAVE ON PURPOSE The same modifiers cover the part of a backend you cannot ask for on demand: • Random latency — a min–max range drawn fresh on every request, so the page under test stops seeing a metronome. • A simulated timeout — it waits, and then fails the way a real network timeout does: a TimeoutError for fetch, the timeout event for XMLHttpRequest. That is neither of the outcomes you already had, since latency succeeds late and blocking fails at once, so code that branches on a timeout finally reaches the branch it was written for. • Chaos, per rule — 20% a 500, 10% a timeout, the rest business as usual. The successful share is simply whatever you leave over, so the numbers cannot contradict each other. • A call limit — the first N calls go through and everything after them answers with the status you choose (429 by default). It is the only way to see what your interface does when something stops working AND does not come back. • Intermittent failure — one request in every N fails, and never the first, so you see the rule work before you see it break. The last two are the only things in the extension that remember anything between requests. The count belongs to the page: reloading starts it over, two tabs count separately, and it is never written to disk. With several of these on one rule the order runs from what you can predict to what nobody can — call limit, then intermittent failure, then chaos. HIT EXACTLY THE REQUESTS YOU MEAN Match by URL or host — contains, exact, regex or wildcard — then narrow it down by HTTP method, by a request header, by what's in the request body, or by which page is making the call, and list the URLs that should be left alone even when they match. Paste a real URL into the test box and the form tells you straight away whether the pattern and the exclusions would catch it, before you save anything. Pin a rule to a single tab when you don't want it affecting everything else you have open. And because GraphQL sends every operation to the same endpoint, matching on the body is what finally lets you mock one operation without touching the rest — and rewriting a single field of the outgoing body lets you change variables.userId without pasting a copy of your query into the rule, where it would go stale the next time the front end adds a field to it. SWITCH A WHOLE STATE AT ONCE A scenario is one API and several named variants of it — Login → Success / Invalid credentials / Backend down — with one variant live at a time. Rules belonging to a variant that isn't live aren't merely skipped: the engine never looks at them. You switch from a dropdown in the popup, and the exclusion is per scenario, so two services can be in different states at the same moment. Six ready-made scenarios spare you the empty list: Typical HTTP errors (401, 403, 500, 503, and a request that hangs for thirty seconds and then fails), REST collection (a list, a detail and a create call, across four states), Sign-in (a valid token, wrong credentials, a locked account and a second factor), Rate limit (with Retry-After in both of its forms), Pagination (first page, a middle one, the last, and empty) and GraphQL response (data, a partial response, and errors returned with a 200 — which is the shape that catches people out). Every variant arrives with its rule already written, body included, so switching to it shows the real thing in your app instead of a named placeholder you still have to fill in. KEEP TWO JOBS APART Everything you have lives inside a project: its rules, groups, scenarios, variables, environments, scope, active environment, bin and activity. Only the active project is shown and applied, so the client you are not working on today cannot answer one of your requests, and cannot lend you a variable that happens to have the same name as yours. You switch from the header of the options page or from the popup, and both keep up with each other without a reload. With a single project there is no picker to see at all. REUSE THE SAME RULES EVERYWHERE Write {{variables}} into bodies, headers, redirect URLs and query parameters, then define environments — Local, Dev, Staging, Prod — that override only the values which actually change. Switch between them from the popup, and the same set of rules follows you from localhost to staging. A rule can also fill a variable in from a response: point it at a JSON field or at a regular expression, and from then on {{JWT}} interpolates the token your login endpoint just issued. Nothing is captured until you pick a variable for a rule, and a captured value lives in session memory only — it never reaches disk, it is never written into an export, and it is gone when you close the browser. DON'T TYPE WHAT YOU ALREADY HAVE The same Import button reads five kinds of file and tells them apart by their own contents, so you cannot pick the wrong one: • A Net Tinker export — rules, groups, scenarios, variables and environments. • An OpenAPI or Swagger spec (3.0, 3.1 and 2.0, in JSON): every endpoint, method and response code becomes a rule with its URL pattern, its status and its body already written, and an endpoint with several response codes becomes a scenario. • A Postman collection (v2.0 and v2.1): each saved response example becomes a mock with the real status, headers and body — nothing invented — and several examples of one request become a scenario. A Postman environment export brings its variables across too. • A HAR capture — the traffic your browser actually recorded, turned into mocks with the status, headers and body a real server returned. It is the only importer that brings something that really happened, so it tells you how many of the new rules carry credentials, and which kind, instead of quietly stripping them behind your back. • A ModHeader profile, with its headers, its URL filter and its exclusions. Before anything is built, a spec or a collection shows you every endpoint it found and lets you untick the ones you don't want: what you don't tick is never created. Everything arrives switched off, so a hundred new rules change no request until you turn one on, and whatever could not be translated is listed with the reason instead of being dropped in silence. BUILD RULES FROM REAL TRAFFIC Net Tinker adds a panel to Chrome DevTools listing the requests of the page you are inspecting. One click turns any of them into a rule — and "Mock" fills in the real status, headers and response body for you, so you start from what the server actually returned instead of typing a fixture by hand. GraphQL operation names are detected and shown, so a list of calls to a single /graphql endpoint is finally readable. Any captured request can also be copied as a curl command or as a fetch() call, and the whole session exported as a standard HAR file — with credentials redacted by default, and response bodies left out unless you ask for them. TAKE THE RULES WITH YOU Copy any rule as a Playwright or Cypress mock and paste it straight into your test suite — or copy the whole set at once. Rule types that can't be translated come out as a comment saying why, never silently dropped, and credentials are redacted with the snippet itself telling you what it hid. You can also copy a rule as a curl or fetch() call to the endpoint it intercepts, when what you want is to compare your mock against the real thing. An exported set is a single JSON file meant to live in your repository next to the code it fakes: fields always come out in the same order, so editing one of them shows one changed line in a diff instead of a whole rule, and the file points at its own schema, so an editor validates and autocompletes it with no setup on your side. STAY IN CONTROL • Choose where it works: everywhere, only on localhost, or only on domains you list. Outside that scope Net Tinker doesn't touch the page at all — it removes its own patches rather than filtering later — and the toolbar icon says so. • When two rules match the same request, the one lower in the list wins, and you move rules up and down to decide which one that is. • Narrow a long list by name, URL, description or tag, by rule type, by group, or by scenario and variant — including the two that are hardest to find any other way: the rules in no group, and the rules outside every scenario. Filtering only hides, it never reorders, so the list can't mislead you about which rule wins; a line above it says how many of how many you are seeing and reminds you that a hidden rule still competes. • Select everything the filter is showing and enable, disable, export or delete it in one go. The counter says how many of your total are selected and how many of those are out of sight, and the confirmation before a delete tells you how many rules would be left. • Group rules and switch a whole group on or off in one click. A rule's group reads as a tag at the front of its row. • See exactly which rule touched which request, whether it reached the network, how much delay it added, and turn the culprit off right there. • Export and import rules to share a setup — with an option to strip credentials first, so you don't hand someone your tokens by accident, and a warning when an import would collide with rules you already have. An import can also replace everything instead of merging, so a set of rules kept in a repository can be put back exactly as it was. • Undo a delete. The last ten deletions are kept, and restoring one undoes the whole gesture: deleting two hundred rules on a filter is one entry, not two hundred. A rule that comes back without the scenario variant it belonged to comes back switched off, and says so, rather than quietly applying itself to real traffic. • A built-in help page explains what each rule type does and walks through the reasons a rule might not be firing. • Light and dark themes, following your system setting. Your rules run from the moment the page loads, whether or not DevTools is open, and nothing puts a "this browser is being debugged" banner across your tabs. PRIVACY Everything is stored locally in your browser. There is no server, no account, no analytics and no tracking. Requests shown in the DevTools panel live only in memory while DevTools is open: nothing is written to storage unless you turn one of them into a rule or export a HAR yourself. Recording a tab is the one feature that does keep a log, and only while you have it switched on: it holds the 200 most recent requests of that tab, locally, and one click empties it. Net Tinker needs broad host access because it cannot know in advance which site you will want to create a rule for. That access is used only to run the rules you configure yourself. It declares two permissions in total: storage, and that host access. Nothing else — no tabs, no scripting, no browsing data. The best-known tool in this category declares eleven, plus the same host access. NO LIMITS AND NO UPSELL Every rule type is free, and there is no cap on how many rules you create or keep active. That is worth saying plainly, because it is where comparable tools draw their paid line — the best known one stops you at five rules, three of them active at a time. WHAT IT CANNOT DO It acts on the requests a page makes itself with fetch or XMLHttpRequest. Images, stylesheets, page navigations and anything a site's own service worker asks for are out of its reach, and the DevTools panel says so rather than offering you a rule that would never fire. Specs and collections are read as JSON; a YAML file is recognised only so it can tell you to convert it first. Useful for testing APIs, simulating backend errors, exercising the loading and error states of your frontend, or debugging an integration without depending on a real environment. Available in English and Spanish, and you choose which: the interface follows your browser unless you tell it otherwise, from the globe in the options header. The choice covers the popup, the options page, the DevTools panel and the help.