Fire a real cross-origin request from this page and see exactly what the browser does: verdict, preflight behavior and every Access-Control header. Paste any response headers to validate them against your own frontend origin, generate correct CORS config for nginx, Apache, PHP, Express or Cloudflare, and decode that cryptic CORS console error into the exact server-side fix. Built entirely in your browser — no proxy, nothing uploaded.
The API works in Postman, works from curl, works when you paste the URL in a
tab — and throws blocked by CORS policy the moment your frontend
calls it. That is because CORS is enforced by the browser, not the
server: the server just adds Access-Control-* headers, and the
browser decides whether your JavaScript is allowed to read the response.
Postman and curl never enforce it, which is exactly why they cannot help you
debug it. This tester runs the real thing — a genuine cross-origin request
from your browser — plus the analyzer, config generator and error decoder
to fix whatever it finds.
Everything runs as plain JavaScript in this page. The URLs you test and the headers you paste are never uploaded anywhere — there is no backend.
Enter an API URL, pick a method, add a custom header to trigger the preflight — get the real browser verdict.
Paste response headers from curl -I or DevTools and validate them against any frontend origin.
Get ready-to-paste CORS config for nginx, Apache, PHP, Express or Cloudflare — with the security notes.
Paste the console error and get the exact cause and fix — preflight, credentials, missing headers.
Honest limitation: the browser sends Origin: https://systron.net (this page's own origin) — JavaScript is forbidden from spoofing the Origin header, with no exceptions. This test tells you exactly what a browser user from this origin experiences. To validate a different frontend origin, use the Header Analyzer tab with headers from curl -I or DevTools.
The analyzer applies the exact rules a browser applies: origin match (exact, wildcard, or reflected), the credentials vs wildcard conflict, preflight method and header coverage, and Vary: Origin on the responses that reflect a specific origin.
Output: nginx server/location block, Apache .htaccess with mod_headers, PHP header() calls for a plain API endpoint, Express cors options, and the Cloudflare note — each with the security reasoning: why reflecting any incoming Origin with credentials is an open door, and why a wildcard and cookies do not mix.
Matches the standard Chrome, Firefox and Edge CORS messages: missing ACAO header, wildcard-with-credentials, preflight failures, disallowed method, disallowed header, credential-less cookies, mixed content and redirect loops — and explains the server-side fix for each. If the error is not one of the known patterns, the output tells you honestly and lists what to check.
Everything above runs in JavaScript in your browser. The URLs you test and the headers you paste are never uploaded — there is no backend to upload to.
| Check | Passes when | Why it matters |
|---|---|---|
| Origin match | ACAO equals your origin exactly, or is * | The browser compares strings — a trailing slash, wrong scheme (http vs https) or a missing port means a silent block. Subdomains do NOT match: api.example.com is not covered by https://example.com. |
| Credentials vs wildcard | Not both credentials and ACAO: * | ACAO * with Access-Control-Allow-Credentials is invalid per spec — the browser blocks it. Cookies need the exact origin spelled out. |
| Preflight method coverage | ACAM contains your method | Preflight asks "is POST allowed?" — a missing method in the ACA-M list kills the request before it is ever sent. |
| Preflight header coverage | ACAH covers every custom header | Authorization or a custom X- header not listed in ACA-H (and Content-Type: application/json) forces a preflight that must succeed first. |
| Vary: Origin | Present whenever the origin is reflected | Without it, a shared cache can serve one origin's allowed response to another origin — a security issue and a source of maddening intermittent bugs. |
| Status code on preflight | 2xx or 3xx on the OPTIONS response | A 404 or 405 on OPTIONS is a preflight failure even if the headers are right — route OPTIONS in your framework, do not just add headers. |
| Exposed headers | ACAE lists the headers your JS reads | JavaScript can only read simple response headers plus the ones in Access-Control-Expose-Headers — your custom X-Total-Count stays invisible without it. |
CORS is enforced by the browser, not the server. Postman and curl send the request and print the response; they never check Access-Control headers. A browser blocks your JavaScript from reading the response unless the server opted in. If it fails here, it fails for your users in Chrome, Firefox and Safari too.
It sends this page's origin (https://systron.net). The Origin header is a forbidden header name in the Fetch specification — JavaScript can never set it, and that is a good thing: the whole security model depends on the browser, not the page, deciding the origin. To validate what a different frontend origin would experience, grab the response headers with curl -I or DevTools and run them through the Header Analyzer tab with your origin — it applies the exact same rules the browser does.
Before certain cross-origin requests, the browser automatically sends an OPTIONS request asking the server for permission: this origin, this method, these headers. It happens for methods other than GET, HEAD and POST, for Content-Types other than form/text/plain, and whenever custom headers like Authorization are attached. If the preflight fails, the real request is never sent. Test it here by picking PUT/DELETE or adding a custom header.
By specification, the wildcard cannot be combined with credentials — a browser rejects the response outright. With cookies (fetch credentials: 'include' or XMLHttpRequest withCredentials), the server must echo the exact origin AND send Access-Control-Allow-Credentials: true. Wildcard is only valid for public, credential-free APIs.
Only with an allowlist. A server that blindly echoes any incoming Origin together with Allow-Credentials: true is telling every website on the internet it may read responses with your users' cookies — a CSRF-class vulnerability. The generated configs match the origin against an explicit list first and only echo it if it is on the list, and add Vary: Origin so caches behave.
The OPTIONS route is not handled. Frameworks only answer the methods your routes declare — a POST /api/data route leaves OPTIONS /api/data unmatched. Handle OPTIONS explicitly (or use the framework's CORS middleware, which does it for you): respond 2xx with the Access-Control headers. A preflight must get a 2xx/3xx status or the browser stops before the real request.
Then the browser will always block it, and no frontend change fixes that — CORS headers must come from the server (or a CDN in front of it). The correct pattern is a thin same-origin backend endpoint that proxies the request, or asking the API provider to enable CORS for your origin. The Config Generator gives you the proxy-side snippet so at least your own part is correct.
No. The live test is a direct browser fetch to the URL you typed — the same as if your own code called it. Header analysis, config generation and error decoding are pure JavaScript in this page. There is no backend, no proxy and no logging: private API URLs and internal hostnames never leave your machine.
Our support team is here to assist you around the clock. Get Expert Help, Anytime.
