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

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:

1. Open DevTools and select the Mokup panel.
2. Enable recording.
3. Use the application normally so the real request appears in Live.
4. Choose Create Mock on that request.
5. Change the status code, response body, or delay.
6. 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.