Modern web apps often depend on backend APIs, third-party services, authentication flows, feature flags, and HTTP headers. That can make frontend testing frustrating when the backend is unavailable, incomplete, slow to change, or controlled by another team.
Fortunately, Google Chrome and Microsoft Edge both include a powerful DevTools feature called Local Overrides. With Local Overrides, you can intercept a response in your browser and replace it with a local version. You can also override HTTP response headers, which is useful when testing caching behavior, security headers, CORS-related behavior, content types, and other browser-level concerns.
This article walks through how to override API responses and HTTP headers directly from DevTools.
What Are Local Overrides?
Local Overrides let your browser use a local file instead of the response that normally comes back from the server.
For example, imagine your frontend calls this API:
GET https://example.com/api/user/profile
The real API might return this:
{
"name": "Tom",
"role": "User",
"isAdmin": false
}
With Local Overrides, you can make your browser behave as if the API returned this instead:
{
"name": "Tom",
"role": "Administrator",
"isAdmin": true
}
The server did not change. The API did not change. Other users are not affected. The override only applies locally in your browser while you are using DevTools with overrides enabled.
When Is This Useful?
Overriding API responses and headers is useful when you need to test scenarios that are hard to reproduce naturally.
- Testing empty states: Make an API return an empty list.
- Testing error states: Change a successful response into an error-like payload.
- Testing feature flags: Turn a feature on or off in the response.
- Testing user roles: Pretend the current user is an admin, manager, guest, or restricted user.
- Testing large payloads: Add extra records to check scrolling, pagination, or performance.
- Testing headers: Modify headers such as
Cache-Control,Content-Type, or security-related headers. - Working around slow backend changes: Build and test frontend behavior before the backend is finished.
Important Limitation
Local Overrides are a browser-side debugging tool. They do not modify the real server, database, API, or deployed application.
That means:
- Only your local browser sees the overridden response.
- Your teammates will not see the override unless they create the same override locally.
- The override is for testing and development, not production behavior.
- If you close DevTools or disable overrides, the browser goes back to using the real server response.
Step 1: Open DevTools
Open the website or web application you want to test.
Then open DevTools:
- Chrome / Edge on Windows/Linux: Press
Ctrl + Shift + I - Chrome / Edge on Mac: Press
Cmd + Option + I
You can also right-click the page and choose Inspect.
Step 2: Go to the Network Panel
In DevTools, open the Network tab.
If the Network tab looks empty, refresh the page. DevTools needs to capture the browser’s network activity while the page loads or while you interact with the app.
To make API requests easier to find, click the Fetch/XHR filter. This usually narrows the list to API calls made with fetch or XMLHttpRequest.
Step 3: Find the API Request You Want to Override
Click through the application until the API request you care about appears in the Network panel.
For example, you might see requests such as:
/api/users /api/profile /api/orders /api/products /api/feature-flags
Click the request and inspect the response. In most cases, you will use the Response tab or the Preview tab to confirm that you found the correct API call.
Step 4: Override the API Response Body
Once you find the request, right-click it in the Network panel and choose:
Override content
The browser may ask you to choose a local folder where override files will be stored. Choose or create a folder on your machine, such as:
devtools-overrides
Chrome or Edge may ask for permission to access that folder. Allow access.
After that, DevTools creates a local copy of the response. You can edit that local copy directly inside DevTools.
Example: Original API Response
{
"items": [
{
"id": 1,
"name": "Basic Plan",
"price": 10
},
{
"id": 2,
"name": "Pro Plan",
"price": 25
}
]
}
Example: Overridden API Response
{
"items": [
{
"id": 1,
"name": "Basic Plan",
"price": 10
},
{
"id": 2,
"name": "Pro Plan",
"price": 25
},
{
"id": 3,
"name": "Enterprise Plan",
"price": 99
}
]
}
After editing the response, save the file:
- Windows/Linux:
Ctrl + S - Mac:
Cmd + S
Refresh the page or trigger the API call again. The browser should now use your local overridden response instead of the real server response.
Step 5: Confirm That the Override Is Working
Go back to the Network panel and trigger the request again.
When an override is active, DevTools usually marks the request to indicate that the response has been overridden. You can also confirm by checking the response body. If you see your edited JSON instead of the original JSON, the override is working.
How to Override HTTP Response Headers
You can also override response headers for a request.
This is useful when testing browser behavior related to caching, MIME types, security policies, downloads, or cross-origin behavior.
Common headers you may want to test include:
Cache-ControlContent-TypeContent-DispositionContent-Security-PolicyX-Frame-OptionsAccess-Control-Allow-Origin
Option 1: Override Headers from the Network Panel
Open the Network panel and select the request you want to modify.
In the request details, open the Headers tab. Find the Response Headers section.
In Chrome and Edge, you can edit supported response headers locally through DevTools. Depending on your browser version, you may see an edit icon or an option to override headers.
You can then change an existing header or add a new one.
Example: Change Cache Behavior
Original response header:
Cache-Control: max-age=3600
Overridden response header:
Cache-Control: no-store
This lets you test how the application behaves when the browser is instructed not to store the response.
Example: Change Content Type
Original response header:
Content-Type: text/plain
Overridden response header:
Content-Type: application/json
This can be helpful when debugging an API that returns the right body but the wrong MIME type.
Example: Test a Content Security Policy
You can also experiment with a Content-Security-Policy header.
Content-Security-Policy: default-src 'self'; img-src 'self' https:; script-src 'self'
This is especially useful when you want to test how a stricter security policy affects your application before changing server configuration.
Where Are Overrides Stored?
DevTools stores overrides in the local folder you selected when enabling Local Overrides.
Inside that folder, DevTools creates files that mirror the URLs being overridden. For response header overrides, DevTools may also create special metadata files used to track the overridden headers.
You usually do not need to manage these files manually. It is often easier to edit overrides directly from DevTools.
How to Disable an Override
When you are done testing, you can disable overrides.
In DevTools, go to the Sources panel and find the Overrides section. From there, you can remove individual overridden files or disable Local Overrides entirely.
You can also delete the local override files from the folder you selected earlier.
Troubleshooting
The Override Is Not Working
If your override is not being applied, check these items:
- Make sure DevTools is open.
- Make sure Local Overrides are enabled.
- Make sure you saved the modified response file.
- Make sure the request URL is exactly the one you overrode.
- Disable browser cache while DevTools is open.
- Hard refresh the page.
- Check whether the app is using service workers, which can also intercept requests.
The App Still Shows Old Data
The frontend may be caching data in memory, localStorage, IndexedDB, or a client-side state manager. Try refreshing the page, clearing site data, or restarting the browser tab.
I Edited the Wrong Request
This is common. Many apps make multiple similar API calls. Use the request URL, request method, payload, response body, and timing to confirm that you are overriding the correct request.
The Header Override Does Not Affect the Behavior I Expected
Some browser behaviors happen very early in the request lifecycle. Also, certain requests, redirects, preflight requests, service workers, and cached responses can make header testing more complicated. If a header override does not appear to work, simplify the test case and verify the exact request being modified.
Practical Testing Scenarios
Scenario 1: Test an Empty State
Change this:
{
"orders": [
{
"id": 1001,
"total": 49.99
}
]
}
To this:
{
"orders": []
}
Now you can test whether the UI properly displays an empty state message such as “No orders found.”
Scenario 2: Test a Permission-Based UI
Change this:
{
"user": {
"name": "Tom",
"permissions": ["read"]
}
}
To this:
{
"user": {
"name": "Tom",
"permissions": ["read", "write", "delete"]
}
}
Now you can test whether admin buttons, edit screens, or restricted actions appear correctly.
Scenario 3: Test a Backend Error Shape
Change a normal response into an error-like response:
{
"error": {
"code": "PAYMENT_FAILED",
"message": "The payment could not be processed."
}
}
This lets you check whether the frontend displays useful error messages.
Scenario 4: Test a Larger Dataset
Add many more records to an API response to test scrolling, pagination, table rendering, or layout problems.
Best Practices
- Keep overrides small and focused. Change only what you need for the test.
- Name your override folder clearly. Something like
chrome-devtools-overridesis easier to recognize later. - Document what you changed. If you are testing a bug, note which response or header you modified.
- Do not confuse overrides with real fixes. Overrides are for local testing only.
- Turn overrides off when you are done. Otherwise, you may accidentally debug against fake data later.
Final Thoughts
Google Chrome and Microsoft Edge are both Chromium-based browsers, so their DevTools are very similar. The exact menu labels may vary slightly between versions, but the general workflow is the same.
Local Overrides are one of the most useful but underused features in Chrome and Edge DevTools. They let frontend developers, QA engineers, and full-stack developers test difficult scenarios without waiting for backend changes or manipulating real data. Use them to mock API responses, test edge cases, experiment with HTTP headers, and debug browser behavior more quickly.