CORS explained: why the browser blocks your request

Browsers follow the same-origin policy: a script running on one origin may not read responses from another origin unless that other server allows it. CORS (Cross-Origin Resource Sharing) is the mechanism a server uses to say “yes, this origin may read my responses.”

What counts as an origin

An origin is the combination of scheme, host, and port. http://localhost:5173 and http://localhost:3000 are different origins because the ports differ. So are http://example.com and https://example.com, and example.com and api.example.com.

Who enforces it

CORS is enforced by the browser, not by the server. That has two surprising consequences. First, curl, Postman, and backend code never see CORS errors, because they do not apply the policy. Second, the request often does reach the server; the browser just refuses to hand the response to your JavaScript. CORS protects users’ data in the browser. It is not a way to stop other servers from calling your API.

Simple requests

For a so-called simple request, such as a GET or a POST with a form-style content type and no custom headers, the browser sends the request with an Origin header and checks the response:

GET /api/items HTTP/1.1
Host: localhost:3000
Origin: http://localhost:5173

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://localhost:5173
Vary: Origin
Content-Type: application/json

If Access-Control-Allow-Origin matches the page’s origin (or is *), the script can read the response. Otherwise you get a CORS error in the console.

Preflight requests

Anything beyond a simple request, such as Content-Type: application/json, an Authorization header, or methods like PUT and DELETE, triggers a preflight. The browser first sends an OPTIONS request asking for permission:

OPTIONS /api/items HTTP/1.1
Origin: http://localhost:5173
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 600

Only if the preflight succeeds does the browser send the real request. Access-Control-Max-Age lets the browser cache the answer for a while (browsers apply their own upper limit). A common bug is a server that requires authentication on every route, including OPTIONS, so the preflight fails with 401 before the real request is ever sent.

Cookies and credentials

By default, cross-origin fetch() does not send cookies. To include them, the client sets credentials: "include" and the server must respond with Access-Control-Allow-Credentials: true and a specific origin. The wildcard * is not allowed together with credentials.

Key takeaways

• The fix for a CORS error is almost always on the server or in a development proxy, not in your fetch() call.
• Allow specific origins rather than * for anything private, and send Vary: Origin when the header value depends on the request.
• mode: "no-cors" does not bypass CORS. It gives you an opaque response whose body and status you cannot read.

For the exact console messages and step-by-step fixes, see Fix: Access to fetch at ‘…’ from origin ‘…’ has been blocked by CORS policy.