CORS Header Checker
Compare CORS response headers with an origin, method, request headers, and credentials context.
Enter the browser Origin value, not a page URL with a path.
PUT, PATCH, DELETE and other non-safelisted methods normally preflight.
Names only. Content-Type and Range also depend on their values.
CORS Analysis Result
A header snapshot is not the whole request
Preflight status, redirects, route-specific headers, credential mode and the exact request-header values can all change the browser result. Confirm the failing request in DevTools after fixing the header values.
Why a request can work in cURL and still fail in the browser
CORS is a browser sharing rule layered on top of HTTP. The server can return a perfectly ordinary 200 response and a command-line client can read it, while browser JavaScript is denied access because the response does not opt in to the calling origin.
The important comparison is between the real browser request and the response that came back: the serialized Origin, whether credentials were included, the method, and any request headers that make a preflight necessary. Looking at Access-Control-Allow-Origin alone often misses the reason a request is blocked.
Give the check the same context as the failing request
Paste the response headers from the failing network entry, then add the Origin, method and request-header names shown in DevTools. Mark whether the cross-origin fetch includes credentials. That last detail matters because * stops acting as a wildcard for several CORS response headers when credentials mode is include.
Origin: https://app.example.com Method: POST Request headers: Content-Type, Authorization Credentials: include
What the browser actually compares
Access-Control-Allow-Origin is not a comma-separated allowlist. For a credentialed request it must be the exact allowed serialized origin, and Access-Control-Allow-Credentials must be exactly true.
A non-safelisted method or request header can require OPTIONS first. Authorization must be named explicitly; an Access-Control-Allow-Headers wildcard does not cover it.
Content-Type and Range can avoid preflight only for particular values. A field containing header names cannot determine those value-level conditions.
When a server chooses a specific allow-origin dynamically, Vary: Origin keeps shared caches from serving a response selected for a different caller.
When the headers look right but the browser still blocks
- The OPTIONS route returns different headers or a redirect.
- An API gateway adds CORS headers to success responses but not 4xx or 5xx responses.
- The request sends Authorization or another non-safelisted header that was not included in the preflight response.
- The frontend sends credentials while the response relies on wildcard values.
- The requested Content-Type is not one of the CORS-safelisted media types.
- A CDN cached an origin-specific response without Vary: Origin.
Where a pasted-header check stops
No network request is made here, so the report cannot see DNS, redirects, TLS, status codes, OPTIONS routing, actual request-header values, browser extensions or credentials that DevTools may show. Treat the report as a comparison of the text you entered, then confirm the real exchange in the browser.
The browser standard behind these checks
The CORS protocol and wildcard behavior are defined in the WHATWG Fetch Standard. MDN's CORS guide is a readable companion when you want concrete browser examples, especially around credentialed requests and preflights.
WHATWG Fetch — CORS protocol·MDN — Cross-Origin Resource Sharing