How to test 500, 404, and 429 API responses in Chrome without touching the backend

Charles — Sat, 29 Aug 2026 09:01:17 +0000

A frontend screen is easiest to check on the happy path: the API returns 200, the JSON has the expected shape, and the UI looks fine.

Then production returns something else.

404 because a resource was removed
429 after the user hits a rate limit
500 when an upstream service fails
an empty array that nobody tested
a response that takes five seconds instead of 200 ms

Reproducing each case through the backend can take coordination. Temporary branches in application code also need to be removed later. Browser-side response mocking offers another option for manual UI testing.

What Chrome already provides

Chrome Local Overrides works well for replacing a response body or header, while Request conditions can block or throttle matching URLs. Reusable 404, 429, 500, empty, and delayed responses are more convenient when they can be saved and switched without recreating each setup.

A practical test matrix

For a user-details endpoint such as:

GET /api/users/42

The following cases form a useful manual test matrix.

404: the resource does not exist

{
  "error": "User not found"
}

Things to check:

Does the page show a useful empty or not-found state?
Does it avoid rendering stale user data?
Can the user navigate somewhere useful?

429: the client is rate limited

{
  "error": "Too many requests",
  "retryAfter": 30
}

Things to check:

Does the UI stop sending the same request repeatedly?
Is retry behavior clear?
Does the page preserve the user's work?

500: the server failed

{
  "error": "Internal server error"
}

Things to check:

Does the screen leave loading mode?
Is retry available where it makes sense?
Does an error in one panel break the whole page?

Add a delay to each response as a separate check. A UI that handles a fast error may still behave badly when the request stays pending for several seconds first.

Turning a real request into a reusable mock

I built Mokup, a DevTools extension that keeps these response scenarios inside Chrome instead of requiring a separate mock server or proxy.

Mokup's Live tab captures the real request before turning it into a reusable mock rule.

The workflow is:

Open DevTools and select the Mokup panel.
Enable recording.
Use the application normally so the real request appears in Live.
Choose Create Mock on that request.
Change the status code, response body, or delay.
Enable the rule and trigger the request again.

The captured response becomes an editable rule for the body, status code, and delay.

Because the rule starts from a captured request, the URL, method, and response shape do not need to be retyped from memory. Several cases can be saved and toggled while working on the screen.

Saved rules stay in the Mokup panel, so scenarios can be switched without editing application code.

Mokup stores its rules locally in Chrome. It does not require a separate mock server, a proxy process, or changes to application code.

When an extension is the wrong tool

Mokup is meant for quick browser-side iteration. It is not a replacement for every mocking approach.

Use Chrome Local Overrides when you need a simple body or header edit and the native workflow is enough.

Use MSW or test-runner interception when the mock belongs in automated tests, should run in CI, or needs to be shared and reviewed with the codebase.

Use a mock server when several clients need the same fake API or when the contract itself is the artifact your team is testing.

Mokup currently intercepts browser Fetch/XHR traffic in the inspected page. It is not a full network proxy and is not the right tool for navigation requests, WebSockets, or binary-response workflows.

A small error-state checklist

Before treating a screen as done, run its main request through four cases:

normal response
empty response
slow response
error response

This check targets common failure modes: loading indicators that never stop, buttons that stay disabled, stale data after an error, and retry loops that make the failure worse.

If Chrome's native tools cover the case, use them. If you keep rebuilding the same response scenarios, save them as rules instead.

Disclosure: I built Mokup. The extension is available on the Chrome Web Store, and the current free plan supports up to three mock rules.

I Built a Chrome DevTools Extension to Mock APIs Without Leaving the Browser

Charles — Sun, 23 Aug 2026 04:03:52 +0000

Every frontend developer knows this pain: the backend isn't ready, it's down, or it returns data that doesn't match the design. You need to build UI against an API that doesn't exist yet.

The usual workarounds all have friction:

Spin up a mock server (json-server, mockoon) — another process, another port, another config to maintain.
Use a proxy tool — powerful, but heavy setup for a quick "give me this response" moment.
Edit your code — comment out the fetch, return hardcoded data, then remember to revert it before pushing.
DevTools Request blocking — blocks requests, but can't craft a response.

So I built Mokup: a Chrome DevTools panel that captures live API requests and turns them into editable mock rules. No proxy. No server. No code changes.

How it works

Install from the Chrome Web Store.
Open DevTools → Mokup tab → enable Recording.
Interact with your app — requests appear in the Live tab with method, URL, status, type, and timing.
Click Create Mock on any request, edit the response body, toggle the rule on. Done — the next matching request returns your mock response.

Mocked requests are logged back to the Live tab so you can see what was intercepted, and you can enable/disable rules globally or per-rule.

Why DevTools?

Because that's where frontend developers already live. You don't open another tool, you don't change your workflow — the mock layer is right next to the network tab you're already looking at.

Details worth knowing

Manifest V3, injected into the inspected tab only when the panel is open (no background interception of your browsing).
Mock rules and captured data stay local — nothing is sent to any server.
Free plan: up to 3 mock rules. Pro license (Polar license-key activation): unlimited rules.
Honest limitation: this is a page-script interception layer for fetch and XHR. It's not a full proxy — navigation requests, WebSockets, and binary responses aren't intercepted (yet).

Try it

If you try it, I'd love feedback — especially on the capture and mock-rule workflow. What's the biggest pain point in your current API mocking setup?

DEV Community: Charles

How to test 500, 404, and 429 API responses in Chrome without touching the backend

What Chrome already provides

A practical test matrix

404: the resource does not exist

429: the client is rate limited

500: the server failed

Turning a real request into a reusable mock

When an extension is the wrong tool

A small error-state checklist

I Built a Chrome DevTools Extension to Mock APIs Without Leaving the Browser

How it works

Why DevTools?

Details worth knowing

Try it