How to Debug CORS Errors in Chrome — DevTools Walkthrough — HeaderSnap ModHeader was removed from Chrome & Edge over a hidden data collector — what happened and what to do
HeaderSnap
← All posts
March 18, 2026

How to Debug CORS Errors in Chrome (and Work Around Them Without Touching the Server)

The error appears in your console. It’s red. It says something about “CORS policy” and “blocked.” The request that should have worked didn’t, and now you need to figure out why.

CORS errors are one of the most common — and most misunderstood — browser errors for frontend developers. This guide walks through how to diagnose them in Chrome DevTools and how to unblock your testing when you can’t immediately change the server.

What CORS Actually Is (The Short Version)

CORS — Cross-Origin Resource Sharing — is a browser security mechanism that controls whether a web page can make requests to a different domain, port, or protocol than the one that served the page.

When your frontend at http://localhost:3000 calls an API at https://api.example.com, the browser first checks if the server allows it. The server signals permission through specific response headers:

  • Access-Control-Allow-Origin — which origins are allowed
  • Access-Control-Allow-Methods — which HTTP methods are allowed
  • Access-Control-Allow-Headers — which request headers are allowed

If the server doesn’t include the right headers, the browser blocks the response. Your JavaScript never sees the data. The error appears in the console.

How Chrome DevTools Shows CORS Errors

The Console Error

The console message is your starting point. A typical CORS error looks like:

Access to fetch at 'https://api.example.com/data' from origin 'http://localhost:3000'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

This tells you exactly what’s missing: the server didn’t send Access-Control-Allow-Origin.

Other variants:

has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin'
header in the response must not be the wildcard '*' when the request's credentials
mode is 'include'.

This means the server is sending Access-Control-Allow-Origin: * but your request includes credentials (cookies, auth headers). In that case, the server must echo back the specific origin, not a wildcard.

Inspecting the Request in the Network Tab

Open Chrome DevTools, go to the Network tab, and find the failed request. Click it and check two sections:

Request Headers — what your browser actually sent. Look for the Origin header — this is what the server sees and needs to allow.

Response Headers — what the server sent back. If Access-Control-Allow-Origin is missing entirely, CORS is not configured on the server. If it’s present but doesn’t match your origin, there’s a misconfiguration.

Preflight Requests (OPTIONS)

For non-simple requests — those using methods other than GET, HEAD, or POST, or sending custom headers like Authorization or Content-Type: application/json — the browser first sends a preflight request using the OPTIONS method.

In the Network tab, filter by “OPTIONS” to find it. Check its response headers for:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers

If the preflight fails or returns unexpected headers, the actual request never fires. This is why your API call seems to silently disappear — the OPTIONS request failed first.

The Developer Workflow Problem

You’ve diagnosed the error. You know which headers are missing. But the fix requires a server change — and that means:

  • Waiting for backend deployment
  • Asking a teammate who owns the API
  • Setting up a local proxy
  • Navigating environment-specific CORS configs

For development and testing workflows, this is a real blocker. You understand the problem. You just can’t unblock yourself right now.

How HeaderSnap Helps: Inject CORS Headers Locally

HeaderSnap is a Chrome extension that lets you inject response headers on matching URLs — without touching the server.

For CORS debugging, this means you can add the missing Access-Control-Allow-Origin header to the server’s response as Chrome receives it, making the browser treat the request as allowed — all without the server knowing or changing anything.

Walkthrough: Unblock a CORS Error for Local Testing

  1. Get HeaderSnap at headersnap.com
  2. Click the HeaderSnap icon → Add Rule
  3. Set URL Pattern to the API domain (e.g., https://api.example.com/*)
  4. Set Header Name to Access-Control-Allow-Origin
  5. Set Header Value to your frontend origin (e.g., http://localhost:3000) or *
  6. Set Action to set
  7. Set Header Target to Response
  8. Click Add

Now retry your request. Chrome receives the response, sees the Access-Control-Allow-Origin header added by HeaderSnap, and allows your JavaScript to read the response.

For Credentialed Requests

If your request includes cookies or auth headers, * won’t work — you need the specific origin. Set:

  • Access-Control-Allow-Origin → http://localhost:3000
  • Add a second rule: Access-Control-Allow-Credentials → true

For Preflight Failures

If the OPTIONS preflight is failing, add rules for the preflight response headers:

  • Access-Control-Allow-Methods → GET, POST, PUT, DELETE, OPTIONS
  • Access-Control-Allow-Headers → Authorization, Content-Type (or whatever your request sends)

Verify in the Network tab that the preflight OPTIONS response now includes these headers, then retry the main request.

Important: This Is a Local Testing Tool

HeaderSnap modifies headers in your Chrome browser. It affects only your browser session — it does not change the server, and it does not affect any other user or environment.

Use it to:

  • Unblock your local development testing while waiting for a server fix
  • Diagnose whether a CORS error is purely a missing header (versus something deeper)
  • Test your frontend against a CORS-restricted API before the server is configured

Do not rely on it as a production solution. The correct fix is always to configure CORS properly on the server. HeaderSnap is a developer tool for local testing workflows.

Debugging Checklist

When you hit a CORS error in Chrome:

  1. Read the console error — identify which header is missing or mismatched
  2. Network tab → find the request — check response headers for Access-Control-Allow-Origin
  3. Check for a preflight — filter Network by “OPTIONS”; see if it succeeded
  4. Determine if credentials are involved — wildcard won’t work with credentials
  5. Inject the missing headers locally with HeaderSnap — unblock testing while the server fix is pending
  6. Fix the server — the permanent solution is always server-side CORS configuration

CORS errors are annoying but logical. Once you know what to look for in DevTools, diagnosing them takes under a minute. And with HeaderSnap, you don’t have to wait for a server deployment just to continue testing.