CORS Header Checker
Browser-to-TargetInspect CORS headers via fetch or pasted response.
CORS header checker
Try a CORS fetch and/or paste response headers to inspect CORS configuration. Some cross‑origin sites block reading headers from browsers.
Enter your URL and select the origin. The tool checks CORS headers and shows whether preflight requests will succeed.
Learn More
What is CORS Header Checker?
Frequently Asked Questions
Technical Deep Dive
CORS Header Checker
Check Access‑Control‑Allow‑* headers by attempting a CORS request or pasting raw response headers. Highlights presence of key headers.
CORS failures are response-header problems. This tool reads Access-Control-Allow-Origin from the live response instead of guessing from a blog post.
Check https://httpbin.org/get from this origin. If ACAO is *, credentialed requests will still fail. If ACAO is missing, the browser blocks the body.
This is a browser-to-target request. The destination sees your IP. Do not point it at an internal admin host.
01 CORS Compliance Matrix
| Header | Function | Required for Cookies? | Wildcard (*) Allowed? |
|---|---|---|---|
Allow-Origin | Identifies Permitted Origin | Yes | No (if Credentialed) |
Allow-Credentials | Permits Auth Headers | Yes | No |
Allow-Methods | Permits HTTP Verbs | No | Yes |
Allow-Headers | Permits Custom Headers | No | Yes |
02 Audit Workflow Pipeline
Access-Control directives and verify they match the request parameters.
03 The mental model that fixes most CORS bugs
CORS is not a server firewall and it is not a client setting. It is a rule the browser enforces on behalf of the user: "JavaScript on page A may not read a response from origin B unless B explicitly said page A's origin is allowed." The request usually still reaches the server and the server usually still runs it — the browser just refuses to hand the response body back to your script, and logs a console error.
Three consequences follow. curl and Postman never see CORS errors, because there is no browser in the loop — a request that fails in the app but works in curl is almost always CORS. Adding headers on the client does nothing; only the server's response headers count. And a 500 or a 404 that also lacks CORS headers surfaces in DevTools as a CORS error, hiding the real failure — always check the Network tab's raw response, not just the console.
04 Preflight caching and real-user latency
Any request that is not "simple" — a JSON POST, any PUT/PATCH/DELETE, or a custom header like Authorization — is preceded by an OPTIONS preflight. Without Access-Control-Max-Age, the browser repeats that OPTIONS round-trip before every such call, so a chatty single-page app pays double latency on a slow network.
Set Access-Control-Max-Age: 86400 and the browser caches the preflight result for 24 hours per method+headers combination. Note the ceilings: Chromium caps it at 7200 seconds, Firefox at 86400. Also, the preflight response must be a clean 200/204 with no redirect — a load balancer that 301s OPTIONS to add a trailing slash silently breaks every non-simple request.
05 Why it only breaks in production
Local dev usually runs the API through a framework proxy (Vite's server.proxy, Next.js rewrites, CRA's proxy field). The browser then thinks the request is same-origin and never applies CORS, so the missing headers go unnoticed until the app talks to the API host directly in production.
The fix is to make the server's allowlist explicit and complete: every front-end origin — localhost, the preview/branch deploys, staging, the apex domain and the www variant — listed by exact scheme, host, and port. Reflecting the request's Origin header back unconditionally works but is a known misconfiguration that turns any site into a trusted origin; allowlist instead. Check each origin against the live response with the request above rather than trusting the config file.