CORS Checker & Preflight Analyzer

How This Tool Classifies a Request

This page is an analyzer and a reference, not a live prober. It does not send a request to the URL you type, and no page could: reading another origin's response headers from JavaScript requires that origin's permission, which is the exact thing you are trying to find out. A browser that let a script read those headers without permission would have already defeated CORS. So instead of guessing at a network result, the tool applies the classification rule from the Fetch standard to the method and headers you describe:

Anything else is preflighted. That is the same test the browser makes before it decides whether to send an OPTIONS request, and it is why adding a single Authorization header to a working GET endpoint can suddenly break it: the call that used to go straight out now needs a successful preflight first.

The real specification adds one condition this tool leaves to you. A POST only counts as simple when its Content-Type is application/x-www-form-urlencoded, multipart/form-data or text/plain. A POST carrying application/json — which is most JSON APIs — is preflighted in a real browser. Type Content-Type into the custom headers box to model that case correctly.

The Preflight Handshake

When a request is not simple, the browser pauses it and sends an OPTIONS request to the same URL first. That probe carries Origin, Access-Control-Request-Method naming the method it intends to use, and Access-Control-Request-Headers listing the non-safelisted headers it intends to send. The server has to answer with a 2xx status and echo back permission in Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers. Only then does the real request go out.

Two consequences catch people out. If the preflight fails, the actual request is never sent at all — so a POST that appears to fail may never have reached your handler, and your server logs will show only an OPTIONS. And many frameworks route OPTIONS through the same authentication middleware as everything else, which returns 401 to a probe that browsers deliberately send without credentials. Preflights must be answered before auth runs.

Why the Browser Error Tells You So Little

A blocked cross-origin call surfaces in JavaScript as a generic TypeError: Failed to fetch, while the network panel often shows a perfectly healthy 200. That asymmetry is intentional — the detail is withheld from the page so a malicious script cannot use error messages as a side channel. The specific reason is printed to the browser console instead, and that console line is the single most useful piece of evidence you have. Read it before changing anything.

To see the headers a server genuinely returns, ask from outside the browser, where the same-origin policy does not apply. This reproduces the preflight exactly:

curl -i -X OPTIONS https://api.example.com/data \
  -H "Origin: https://app.example.com" \
  -H "Access-Control-Request-Method: PUT" \
  -H "Access-Control-Request-Headers: authorization,content-type"

Compare what comes back with the expected rows in the table above. A missing Access-Control-Allow-Headers, or one that omits authorization, is the usual culprit.

CORS Header Reference

Every header in the protocol, which side sends it, and what it controls. Request headers are set by the browser and cannot be overridden from JavaScript.

Simple vs Preflighted Requests

The distinction decides whether one HTTP round trip happens or two, so it shows up as latency as well as correctness. The safelisted request headers — the ones that never trigger a preflight — are Accept, Accept-Language, Content-Language and a restricted Content-Type.

Wildcards, Credentials and Server Config

Access-Control-Allow-Origin: * is the permissive setting and the one most tutorials reach for, but it has a hard limit: the browser refuses it outright whenever the request carries credentials. If your frontend sends cookies or uses fetch(url, { credentials: 'include' }), the server must return one concrete origin rather than a wildcard, and must also send Access-Control-Allow-Credentials: true. The header accepts exactly one origin, so serving several frontends means reading the incoming Origin, checking it against an allowlist you control, and echoing it back with Vary: Origin.

The Apache option in the config dropdown currently produces an empty box. These are the equivalent directives for an .htaccess file or a virtual host, with mod_headers enabled:

Header set Access-Control-Allow-Origin "https://app.example.com"
Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"
Header set Access-Control-Allow-Credentials "true"
Header set Access-Control-Max-Age "86400"

Whichever server you use, the same two mistakes account for most failures. The first is applying headers only to successful responses, so a 404 or a 500 arrives without them and the browser reports a CORS error for what is really a routing or crash bug. Nginx's add_header needs the always flag for exactly this reason. The second is answering OPTIONS from an application layer that sits behind authentication or behind a redirect — preflights follow neither, so the probe must be answered directly, at the edge, with a 2xx.

Use Cases

Related Tools