CORS checker. Real browser fetch, real verdict.
Type a target URL. We fire a real browser fetch from digitalheroes.co.in against it across GET / POST / preflight. Whatever the browser allows or blocks IS the answer — no proxy, no simulation. Pinpoints which Access-Control header is missing.
Type a target URL. We run real browser fetch attempts from digitalheroes.co.in against it across four request shapes — simple GET, simple POST, preflight OPTIONS, credentials-mode GET. Whatever your browser allows or blocks IS the verdict. No proxy, no simulation.
HTTPS only. The browser blocks HTTP from this HTTPS page.
Sources used
- WHATWG Fetch — CORS protocol — canonical specification
- MDN CORS reference — header-by-header behavior
- W3C CORS Recommendation — preflight rules + credentialed requests
- MDN CORS error reference — every error string + cause
No data is sent to any external service. Each test issues a real fetch from your browser to the target URL; the browser's CORS error itself is the answer. The source links above are reference documentation only.
Privacy: fetch requests go directly to the target URL from your browser. Digital Heroes never sees them.
Three concepts. Then it makes sense.
1. Same-origin policy is the default. By default, the browser blocks JavaScript on origin A (https://example.com) from reading responses from origin B (https://api.other.com). This stops a malicious site from silently calling your bank's API and reading your account data with your cookies. CORS exists to relax that block in controlled, opt-in ways.
2. The server is the gatekeeper. CORS is enforced by the browser, but configured by the target server. The target server must include Access-Control-Allow-Origin in its response — set to the requesting origin (or * for any origin) — for the browser to allow JavaScript to read the response. No header = browser blocks reading. Wildcard * won't work for credentialed requests.
3. Preflight is the OPTIONS dance. For non-trivial requests (POST application/json, PUT, DELETE, anything with a custom Authorization header), the browser fires an OPTIONS request first to ask the server "can I send this real request?" The server must respond with Access-Control-Allow-Methods + Access-Control-Allow-Headers approving the planned request. Only then does the browser send the real request. Modern API design with JSON bodies means almost every request is preflighted — and almost every CORS bug is a misconfigured OPTIONS handler.
Four jobs this tool covers.
Job 1: API integration debugging. Your app's frontend can't read responses from a third-party API. Run the API URL through this tool to see whether it's a CORS issue (most likely) or something else. The per-request breakdown tells you exactly which shape the API supports — many APIs allow GET but not POST, or allow GET-without-credentials but not credentialed.
Job 2: CORS config verification after deploy. You added CORS middleware to your own API. Run the API URL here from this origin to confirm the headers landed correctly. The four-shape test catches the common gaps — preflight OPTIONS not handled, credentials-mode misconfigured, wildcard-with-credentials mistake.
Job 3: Vendor / third-party API evaluation. Considering integrating a vendor API into your frontend? Run their public endpoints through this tool to see whether browser-side use is supported. If not, you'll need a backend proxy — adds infrastructure cost. Useful pre-decision check before signing up.
Job 4: Diagnose the "works in curl, fails in browser" mystery. The classic CORS headache. The tool gives you the explicit verdict and the recommended server-side fix. Pair with our HTTP Headers Checker to inspect what headers the server is actually sending in response to OPTIONS requests.
Six questions users ask.
What does this tool actually test?
It runs four real browser fetch attempts from this page (origin: digitalheroes.co.in) against the target URL you enter: (1) simple GET — the basic cross-origin request. (2) simple POST with text/plain body — covers form-style POST. (3) preflight OPTIONS — what the browser sends before non-simple requests like POST application/json or PUT. (4) credentials-mode GET — what happens when the request needs to carry cookies. Each attempt reports whether the browser allowed the response, blocked it on CORS, or got a network error. The browser's behavior IS the test — no simulation.
What's a 'simple' vs 'preflighted' request?
Simple requests are GET / HEAD / POST with a Content-Type of application/x-www-form-urlencoded, multipart/form-data, or text/plain — and no custom headers. The browser sends them directly and checks Access-Control-Allow-Origin in the response. Preflighted requests (POST application/json, PUT, DELETE, PATCH, anything with custom headers like Authorization) trigger an OPTIONS preflight first. The server must respond to the OPTIONS with the right Allow-Methods and Allow-Headers before the browser sends the real request. Most modern API requests are preflighted because they use application/json.
What headers must the target send?
For simple requests: Access-Control-Allow-Origin (set to the requesting origin or '*'). For preflighted requests: also Access-Control-Allow-Methods (which methods are allowed) and Access-Control-Allow-Headers (which custom headers are allowed). For credentialed requests (cookies / auth headers): Access-Control-Allow-Origin must be the specific origin (not '*'), AND Access-Control-Allow-Credentials must be 'true'. To expose response headers to JS, also set Access-Control-Expose-Headers. Each missing header maps to a specific browser console error.
Why does the same URL work in curl but not in the browser?
curl doesn't enforce CORS — CORS is a browser-only security model. The browser deliberately blocks scripts on origin A from reading responses from origin B unless B opts in via CORS headers. curl, server-side fetches, mobile apps, and Postman all bypass CORS because they're not browsers. So a public API that 'works' in curl may still be blocked in your browser — the API simply hasn't been configured to allow your origin to read its responses from JS.
Does this work with any URL?
Yes for HTTPS URLs. The browser blocks mixed-content (HTTPS page fetching HTTP URL) so http:// targets fail. Some networks block specific domains; some servers refuse non-browser-shaped requests (rare). The vast majority of public HTTPS URLs work — and the CORS verdict is the answer in either direction (Allow or Block).
Is the URL I check sent anywhere?
It's sent to the target URL itself — that's the whole test. The browser fetches the URL directly (not through any Digital Heroes proxy). Fetch results are processed in your browser. The page is static HTML; the only network requests are the initial page load and the fetch attempts you trigger by clicking Check.
Published .