01
Use the real caller Origin
Enter the frontend's scheme, host and port, not the API URL. The local CORS checker compares that exact Origin with the pasted Allow-Origin field; the browser mode instead uses this site's fixed Origin.
HTTP / Request Debugging
CORS testerfor browser-readable responses
Paste actual and optional OPTIONS response headers, or explicitly run a browser GET from this page.
CORS tester
Actual response headers
OPTIONS response headers (optional)
Pasted headers stay in this browser. Local analysis sends no request.
Result
Paste response headers to begin.
Request conditions
This Origin is for local analysis only. Browser GET uses this page's actual Origin.
Paste response headers to begin.
Your server logs show a 200 response, but fetch still rejects it. The CORS tester separates the HTTP exchange from the browser's decision to expose that response to JavaScript.
Start with headers copied from DevTools; no request is sent. Use the CORS checker conditions for the Origin, method and request headers you actually need, then compare a separate preflight response if the browser would send OPTIONS.
Why use this CORS tester
A response reaching your server is only half the story.
Separate delivery from readability
A plain GET may reach the server and return HTTP 200 while the browser withholds it from JavaScript. This CORS tester checks the actual Access-Control-Allow-Origin value before it calls a response readable; it never treats server success as browser permission.
Keep OPTIONS evidence separate
A JSON POST or Authorization header can trigger OPTIONS before the actual request. If you paste only the final response, the preflight remains unverified. Add the OPTIONS status and headers to see which method or request header was refused.
Trace the two CORS gates
02
Predict whether OPTIONS runs
JSON Content-Type, Authorization and non-simple methods can trigger preflight. Add only request header names; values are irrelevant to this classification. An empty OPTIONS box means the gate remains unverified.
03
Read the current verdict
A changed input immediately disables the old report. Auto analysis waits 350 ms; turn it off to use Analyze or Ctrl/Cmd + Enter. Browser GET is always manual and reports only what page script can observe.
Inspect each browser permission
Exact Origin and credentials checks
Compare one Origin with the actual response. Wildcard Allow-Origin fails with credentials: include, and a specific Origin still needs Allow-Credentials: true. Authorization as a request header triggers its own preflight rule; it is not the credentials switch.
Method and header authorization
The CORS preflight tester checks the OPTIONS status, Allow-Methods and Allow-Headers against the selected method and required header names. It reports missing fields and names separately instead of collapsing every failure into one red badge.
Visible response headers
Read Expose-Headers and Vary without inventing an endpoint test. A particular Allow-Origin may require Vary: Origin for caches, but one copied response cannot establish whether a server reflects every Origin.
Optional real browser GET
Only an explicit click sends a credential-free GET from this page's actual Origin. A readable HTTP error still proves the browser exposed that response. When fetch rejects, this page cannot show the hidden status or headers.
What these results can and cannot prove
- Pasted headers are a simulation
- Local CORS header analyzer results apply to the supplied Origin and text. They are not a live test of that API. If OPTIONS is required but its response is absent, the result is unverified even when the actual response headers look permissive.
- Direct GET uses this page's Origin
- The browser controls Origin. Browser mode cannot impersonate your app's Origin, send a POST or PUT, add credentials, or reveal CORS-blocked response details. A same-origin success does not verify a cross-origin policy.
- No server proxy or security scan
- This CORS checker does not relay arbitrary URLs through a server, scan a list of origins, or send write methods. It also does not label a missing Allow-Origin field a vulnerability: same-origin-only resources may omit it deliberately.
- Some headers remain hidden
- A successful fetch exposes only safelisted and explicitly exposed response headers to page script. A header absent from this view may still exist on the wire. Inspect DevTools or target logs for the complete exchange.
CORS tester questions
Why does a request fail with a CORS error even though the server responded successfully?
The HTTP response can arrive while the browser refuses to expose it to page JavaScript. Check the actual Allow-Origin and credential fields; for a non-simple request, also check the separate OPTIONS response. A server log or curl success alone is insufficient.
What's the difference between a simple request and a preflighted request?
A simple GET can be sent directly, followed by a response read check. JSON POST, non-simple methods or custom headers first need a successful OPTIONS exchange authorizing the Origin, method and header names. The actual response still needs its own Allow-Origin check.
Does checking CORS headers here send my data to a server?
The default local CORS tester analyzes pasted text in your browser and sends no request. Browser GET is a separate, explicit mode: clicking Run sends a GET to the URL from this page, without credentials or custom headers.
Does CORS protect an API from malicious requests?
CORS governs what browser JavaScript may read. It does not replace authentication, authorization or server-side validation; non-browser clients do not enforce the browser's CORS read restriction.
Why doesn't Access-Control-Allow-Origin: * work together with credentials: include?
A credentialed cross-origin response requires a specific matching Origin and Access-Control-Allow-Credentials: true. The browser rejects a wildcard Allow-Origin for this mode. The local analyzer flags that combination in actual and preflight responses.
Need another scenario explained?
Use the CORS tester with real evidence
Copy the actual and, where needed, OPTIONS headers from DevTools. The CORS tester keeps the two decisions separate before you change server configuration.
Local analysis by default; browser GET only after your click.