How to Block API Requests and Simulate Failures in Chrome During Development

Every frontend developer eventually runs into the same problem: you need to test what happens when an API call goes wrong, but your backend is healthy and returning 200s. Maybe you want to see how your app recovers from a 401. Maybe you want to verify your error boundary renders. Maybe you need to confirm that a third-party analytics call isn’t breaking your page when it fails.

There are two distinct approaches here, and they’re often conflated:

1. Blocking a request entirely — the request never reaches the server, or the browser aborts it
2. Triggering a server-side error — the request goes through, but manipulated headers cause the server to return an error response

Both are useful. They test different things. Chrome has native tooling for the first, and a header editor extension handles the second. Here’s how to use each.

---

Method 1: Blocking Requests in Chrome DevTools (No Extension Required)

Chrome’s DevTools has a built-in request blocking feature that requires no extension. It intercepts matching requests and returns a network error before they reach the server — useful for testing how your app handles network failures, removing third-party scripts, or simulating a completely unreachable endpoint.

How to enable request blocking in DevTools:

1. Open DevTools (F12 or Cmd+Option+I on Mac)
2. Go to the Network tab
3. Click the ⋮ (three dots) menu in the Network panel toolbar and select Request Blocking — or just search for it in the command palette (Cmd+Shift+P → “Block request”)
4. Click + to add a pattern
5. Enter a URL pattern — supports * wildcard (e.g., */api/orders*)
6. Make sure “Enable request blocking” is checked

Matching requests will show as (blocked) in the Network tab. Your app sees a network error (net::ERR_BLOCKED_BY_DEVTOOLS), not an HTTP error code.

What this is good for:

• Testing catch blocks and network error handling in fetch/XHR
• Verifying your app degrades gracefully when an external API is unavailable
• Removing analytics or third-party scripts during a debugging session without touching code
• Simulating a complete service outage

The limitation:

DevTools request blocking only works while DevTools is open, and the rules don’t persist between sessions. It’s a scratch-pad tool, not a persistent testing configuration.

---

Method 2: Triggering Server-Side Errors via Header Manipulation (HeaderSnap)

Chrome DevTools can cut a request dead, but it can’t make your server return a 401, 403, or 422. For that, you need the request to actually reach the server — just with the wrong headers.

This is where a header editor extension is useful. By manipulating the headers your browser sends, you can trick your own API into returning the error responses you need to test against.

HeaderSnap is a free Chrome extension that uses Chrome’s declarativeNetRequest API to modify request and response headers. Rules persist across sessions, apply automatically to matching URLs, and don’t require DevTools to be open.

Simulating a 401: Remove the Authorization Header

The most common scenario: test what your app does when authentication fails.

Setup in HeaderSnap:

1. Add a new rule
2. Header name: Authorization
3. Action: remove
4. URL pattern: api.yourapp.com/*
5. Enable the rule

Now every request to your API will go out without the Authorization header. Your server returns a 401. Your app sees a real 401 response — not a network error — and your authentication error handling is tested.

// Your app's existing fetch code — no changes needed
const response = await fetch('https://api.yourapp.com/protected-resource');
// HeaderSnap removes the Authorization header before the request leaves Chrome
// Server returns 401 because no auth header is present
if (response.status === 401) {
  redirectToLogin(); // ← you're now testing this code path
}

Toggle the rule off to restore normal behavior instantly — no code changes, no server configuration, no proxy.

Simulating a 403: Corrupt an API Key Header

For APIs using key-based authentication, you can simulate permission failures by setting an invalid key value:

1. Add a rule: header name X-API-Key, action set, value invalid-key
2. URL pattern: api.yourapp.com/*
3. Enable

Your server receives the request with a bad API key and returns a 403. You can now test your forbidden-state UI, error messages, and fallback behavior.

Simulating a 400: Remove a Required Header

Some APIs require specific headers on every request — X-Request-ID, X-Client-Version, a custom correlation header. Remove one and the server should return a 400 or 422.

1. Add a rule: header name X-Client-Version, action remove
2. URL pattern: api.yourapp.com/*
3. Enable

This is especially useful for testing API validation and verifying that your frontend handles malformed request errors correctly — without having to write and deploy backend changes to introduce the validation.

Using URL Pattern Scoping to Isolate Specific Endpoints

A key advantage over DevTools blocking is precise URL targeting. HeaderSnap supports both glob patterns and regex, so you can scope rules to exactly the endpoint you’re testing:

# Glob: all requests to the orders endpoint
api.yourapp.com/orders*

# Regex: only the POST endpoint for order creation
^https://api\.yourapp\.com/orders$

This lets you simulate failures on one endpoint while leaving others intact — your product list loads fine, but the checkout call returns a 401.

---

Comparing the Two Approaches

	Chrome DevTools Blocking	HeaderSnap Header Manipulation
What the app receives	Network error (ERR_BLOCKED)	HTTP error (401, 403, 400, etc.)
Best for testing	Network failure handling	API error response handling
Persistence	Session only (DevTools open)	Persistent across sessions
URL targeting	Basic wildcard	Glob and regex
Setup required	DevTools open	Extension installed
Requires server cooperation	No	Yes (server must return an error for bad headers)

The right tool depends on what you’re testing. If you want to test catch (networkError) or graceful degradation when a service is unreachable, use DevTools blocking. If you want to test your app’s response to HTTP error codes — 401, 403, 422, 500 — use header manipulation to trigger real server responses.

---

Practical Examples with fetch and XHR

Testing fetch network error handling (DevTools blocking):

// Block the URL in DevTools, then run this
fetch('/api/recommendations')
  .then(res => res.json())
  .catch(err => {
    // err is a TypeError: Failed to fetch
    // Your error UI should render here
    console.error('Network error:', err.message);
  });

Testing fetch HTTP error handling (HeaderSnap header removal):

// Remove Authorization header with HeaderSnap, then run this
const response = await fetch('/api/account');
if (!response.ok) {
  if (response.status === 401) {
    // This is the code path you want to test
    clearSession();
    redirectToLogin();
  }
}

Testing XHR error states (either method):

const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/inventory');
xhr.onload = function() {
  if (xhr.status === 403) {
    showPermissionError(); // ← test this with HeaderSnap API key manipulation
  }
};
xhr.onerror = function() {
  showNetworkError(); // ← test this with DevTools blocking
};
xhr.send();

---

Why Not Use a Proxy?

Charles Proxy, mitmproxy, and similar tools can intercept and rewrite requests, including returning arbitrary responses. They’re more powerful — you can change status codes, response bodies, and headers in any combination.

The tradeoff is setup complexity: proxy tools require installing root certificates, configuring system proxy settings, and maintaining a separate running process. For the majority of testing scenarios — validating how your app handles common HTTP errors — header manipulation in the browser is faster to set up and easier to maintain.

For more complex mock scenarios (custom response bodies, specific JSON payloads, dynamic responses), a proxy or a mock server like MSW (Mock Service Worker) is the right tool.

---

A Note on Chrome’s declarativeNetRequest API

HeaderSnap uses Chrome’s declarativeNetRequest API to apply header rules. HeaderSnap implements modifyHeaders rules only (set, append, remove) — it does not implement the block action type. This is why Chrome DevTools is the right tool for hard request blocks: HeaderSnap manipulates headers, it does not intercept and cancel requests.

---

Testing error states thoroughly requires both network-level failures and server-level HTTP errors. Chrome DevTools handles the first in seconds, no extension required. For persistent, pattern-targeted header manipulation that triggers real error responses — without modifying your backend or setting up a proxy — HeaderSnap is the free option built specifically for this.