Simple requests

A simple request — a GET, HEAD, or plain POST with no custom headers — is always sent, and the server always processes it. What Cross-Origin Resource Sharing decides is narrower and often misunderstood: whether your page is allowed to read the response. That decision rests entirely on one response header, Access-Control-Allow-Origin.

The Inspector below fires a real POST from this page's origin at the live demo API on a different origin — the exact URLs are shown in pane 1 below. Nothing is proxied or mocked. The default run asks the server not to allow the read, so the browser blocks it and you'll see a genuine CORS error in the console. That error is the demo. Switch the control to the allowed variant and the same request becomes readable.

Why does this rule exist, and who enforces it? Your browser attaches your cookies to every request it sends to a site — so without a same-origin policy, any page you happened to open could quietly read your webmail or bank in the background using your logged-in session. CORS is the server's controlled way to opt out of that default: a set of response headers that say "these specific origins are allowed to read my responses." And it is the browser that enforces all of this — to protect its own user, not the server. Tools like curl, server-to-server calls, and native apps ignore CORS entirely, which is exactly why curl can read a response your page cannot. The rules are defined by the WHATWG Fetch standard — not, despite the common search, a "CORS RFC" of its own; the underlying notion of an origin comes from RFC 6454.

One distinction underlies everything on this page: the response always arrives at your browser — status, headers, and body, all of it, visible in the Network tab. CORS is a gate between the browser and your page's JavaScript. "Blocked" never means the response wasn't received; it means the browser refuses to hand it to your code.