By default a page can only read responses from its own origin. To let a page read a response from another origin, the server must opt in with Access-Control-Allow-* headers. The browser enforces this: if the headers do not permit your origin, it blocks the read even though the server replied.
Non-simple requests (custom headers, a JSON body, or methods beyond GET/HEAD/POST) first send an OPTIONS preflight; the server must allow the method and headers before the real request goes out. When the request carries credentials, wildcards stop working: Access-Control-Allow-Origin must be the exact origin (not *) and Access-Control-Allow-Credentials must be true. This exact pairing is the single most common CORS mistake.
Common questions and answers about this topic.
The server replied, but the browser refuses to expose the response to your page because the Access-Control-Allow-* headers do not permit your origin (or method, or headers). This tool shows exactly which header is missing.
For non-simple requests the browser first sends an OPTIONS request to ask the server whether the method and headers are allowed. Only if that preflight passes does the real request go out.
For security, the browser forbids the wildcard when a request sends cookies or auth. You must echo back the exact origin and add Access-Control-Allow-Credentials: true.
No. It is a pure rule engine that runs entirely in your browser; it never sends a network request and nothing you type leaves your device.