Pick Ads
Add your product - start free

Updated October 20, 2026

Get HeaderSwap for Chrome

Home › Extensions › HeaderSwap for HTTP Headers › Guides › Fix CORS errors while developing

How to Fix CORS Errors in Chrome While Developing

By the Pick Ads team · Tested on Chrome · Published October 20, 2026 · Updated October 20, 2026

Answer: A CORS error means the server's response didn't include the headers Chrome needs to let your page read it. Read the reason in the console, then fix the server. Return the right Access-Control-Allow-Origin value, answer preflight OPTIONS requests, and never use * with credentials. Use a browser-side override only for local testing.

Quick steps

  1. Open DevTools > Console and copy the text after "blocked by CORS policy:".
  2. Match it to the table below.
  3. Fix the server's response headers or preflight handling.
  4. Reload and confirm the request succeeds in the Network tab.

Read the error

Chrome logs every CORS failure as "Access to fetch at '<url>' from origin '<origin>' has been blocked by CORS policy:" followed by a reason. Your JavaScript only sees TypeError: Failed to fetch. MDN notes that, for security, the details aren't available to your code, only in the console (CORS errors).

We reproduced the common reasons in Chrome 154 on a local test page (localhost:8001 calling 127.0.0.1:8002):

Message (after "blocked by CORS policy:")What it means
No 'Access-Control-Allow-Origin' header is present on the requested resource.The response has no ACAO header at all.
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'.You sent cookies or auth with credentials: 'include', and the server answered with *.
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present…The OPTIONS preflight response lacks CORS headers.
Response to preflight request doesn't pass access control check: It does not have HTTP ok status.The server answered OPTIONS with an error, such as 405 or 401.
Request header field x-debug is not allowed by Access-Control-Allow-Headers in preflight response.You sent a custom header the server didn't list.

Is it actually a problem?

Yes, if your app needs to read the response. If you only fire a beacon and never read the result, mode: "no-cors" can work. The response becomes opaque: status 0, no headers, no readable body (MDN).

Causes and fixes

CauseHow to checkFix (server)
No ACAO headerNetwork > response headersAdd Access-Control-Allow-Origin: http://localhost:3000 (your dev origin)
* with credentialsRequest uses credentials: 'include' or withCredentialsEcho the exact origin, add Access-Control-Allow-Credentials: true and Vary: Origin
Preflight not handledOPTIONS request fails with 404, 405 or 401Return a 2xx to OPTIONS with CORS headers, before any auth check
Header not allowedCustom header like Authorization or X-DebugList it in Access-Control-Allow-Headers
Method not allowedPUT, PATCH or DELETEList it in Access-Control-Allow-Methods

The real fix (response headers, preflight, credentials)

Response headers. Only the server can grant cross-origin access. MDN's example for one allowed origin is Access-Control-Allow-Origin: https://example.com. Use * only for public APIs, never for private ones. To allow several origins, read the request's Origin header, echo it back if it's on your allow list, and send Vary: Origin (CORS header 'Access-Control-Allow-Origin' missing).

In Nginx, for example:

add_header 'Access-Control-Allow-Origin' 'http://localhost:3000' always;

Preflight. Browsers send an automatic OPTIONS request before "non-simple" requests, such as those with custom headers, methods other than GET, HEAD or POST, or JSON content types. The preflight carries Origin, Access-Control-Request-Method and, optionally, Access-Control-Request-Headers (Preflight request). Your server must answer it with a 2xx status and the matching Allow-Methods and Allow-Headers. Access-Control-Max-Age lets the browser cache that answer.

Credentials. For credentialed requests, the server must not use * in Allow-Origin, Allow-Headers or Allow-Methods. It must name them explicitly and send Access-Control-Allow-Credentials: true (Cross-Origin Resource Sharing).

If you don't control the API, MDN suggests a simple request to avoid preflight, or a proxy you control that adds the headers.

Common mistakes

  • Access-Control-Allow-Origin: * together with cookies or an Authorization header (see the credentials rule above).
  • Auth middleware that rejects the OPTIONS preflight with 401 before CORS headers are added.
  • Setting CORS headers on the request in your frontend code. They belong on the server's response.
  • Two ACAO headers, from both a proxy and your app.
  • Forgetting Vary: Origin when echoing origins, so caches serve the wrong value.

10-minute diagnosis checklist

  1. Copy the console reason.
  2. In Network, find the failing request and check whether there's an OPTIONS request before it.
  3. Compare the response headers with the table above.
  4. Retry with curl -i -X OPTIONS -H "Origin: http://localhost:3000" <url> to see what the server returns.
  5. Fix, reload and confirm.

Local-only workaround with the Allow CORS preset

Warning: a browser-side CORS override hides the problem only on your machine. Your users will still see the error until the server is fixed. Never leave it on for everyday browsing.

When the backend fix is pending and you need to keep working:

  1. In HeaderSwap, create a profile and add the Allow CORS preset.
  2. Limit the profile to the API host, for example api.staging.example.com.
  3. Reload and confirm the error is gone.
  4. Pause or delete the profile when you're done. Premium can auto-expire it after 1 hour, 24 hours or 7 days.

Without an extension, Chrome DevTools can override response headers too: Network > right-click the request > Override headers. Chrome's own example adds Access-Control-Allow-Origin: * (Override HTTP response headers). For a fuller walkthrough of local CORS testing, see test CORS locally.

Test steps

  1. Turn the workaround off and confirm the error is back. That proves the server still needs fixing.
  2. Deploy the server fix to staging.
  3. Test in a clean Chrome profile with no header extensions.
  4. Test with and without credentials, if your app uses both.

Where the extension helps, and where it doesn't

It helps you keep coding while a backend change is in review, and test which headers would fix the error. It doesn't fix production, change preflight status codes, or affect other browsers or users.

Last verified: 2026-10-20

Privacy: HeaderSwap applies rules through Chrome and is designed not to read page content. See the HeaderSwap privacy policy.

FAQ

Is disabling CORS safe? Only briefly, on your own machine, and scoped to your API's domain. CORS and the same-origin policy stop other sites from reading responses with your cookies. A global "allow all" override removes that protection on every site. Turn it off when done, and fix the server for real users.

Why does Postman work but the browser doesn't? CORS is enforced by browsers. Browsers restrict scripts on one origin from reading responses from another unless the server sends the right headers. Postman and curl aren't web pages running under that policy, so they show the response. That proves the API responds, not that CORS is configured.

What is a preflight request? It's an automatic OPTIONS request that Chrome sends before a non-simple request, for example one with an Authorization header or the PUT method. It asks the server which origin, methods and headers it allows. If the server answers with an error status or without CORS headers, the real request is never sent.

Add HeaderSwap to Chrome - Free

Sources

Last verified: 2026-10-20