1. The request and the server's answers

Load an example, or type your own. Everything is evaluated in this page; nothing is sent anywhere. The checker assumes an empty preflight cache and no redirects.

Request, as written in your code

Page origin where the script runs, for example https://app.example.com, or the literal null Target URL Method exactly as written in code; leave empty for the default GET

Mode

Credentials

Request headers one Name: value per line; a repeated name stays a separate entry

Body

Blob type used only for a Blob body

What the server answered

Preflight response optional first line HTTP/1.1 204; then one header per line. Without a status line the status is taken as 200. Actual response headers of the response to the real request; its status does not matter to CORS

Results also update as you type.

2. Verdict, per the Fetch Standard

3. Your browser, right now

These probes construct Request objects in this page and read back what your engine did with them. Constructing a Request sends nothing; the page makes no network call. Each row shows what the Fetch Standard expects next to what your browser produced, and any mismatch is flagged rather than hidden.

4. Self test

Every case below runs through the same evaluator as section 2. Expected values are the Fetch Standard verdicts. Rows marked "spec only" were never measured in a browser by the author; for two of them, a GET with a body and the implicit Content-Type of a string body, section 3 probes your own browser. The last row is a positive control: an assertion written to be wrong. If it ever reports that it held, the suite is not really running.

5. What this checker models, and what it does not

Modelled, in this order

A. Request constructor: method token, forbidden methods, method normalization, no-cors limits, body with GET or HEAD, implicit Content-Type of the body. Fetch Standard 2.2.1 Methods and 5.4 Request class (fetch.spec.whatwg.org/#request-class).
B. Header validation and the forbidden request-header list, which drops headers silently. Fetch Standard 5.1 Headers class and 2.2.2 Headers (fetch.spec.whatwg.org/#forbidden-request-header).
C. CORS-safelisted request-headers, the 128 byte limit, the strict MIME type parse for Content-Type, the single range rule, and the 1024 byte total. Fetch Standard 2.2.2 (fetch.spec.whatwg.org/#cors-safelisted-request-header) and MIME Sniffing 4.4 (mimesniff.spec.whatwg.org/#parsing-a-mime-type).
D. Whether a preflight is needed. Fetch Standard 4.1 Main fetch (fetch.spec.whatwg.org/#main-fetch).
E. The preflight and its checks. Fetch Standard 4.8 CORS-preflight fetch (fetch.spec.whatwg.org/#cors-preflight-fetch), 2.2.3 ok status, 3.3.4 header syntax.
F. The CORS check on the actual response. Fetch Standard 4.10 CORS check (fetch.spec.whatwg.org/#cors-check).

Not modelled

Local Network Access and private network checks. They are browser specific and not part of the Fetch Standard.
Redirects of the actual request. A cross-origin redirect taints the origin, which then serializes as null.
Service workers.
The use-CORS-preflight flag, which forces a preflight (for example XHR upload listeners).
The CORS protocol exceptions to the Content-Type safelist (Fetch Standard 3.3.7).
Access-Control-Expose-Headers, beyond the note that it decides which response headers your script can read.
Mixed content, CORP and COEP.
The preflight cache. The checker assumes it is empty, so a cached earlier answer can make a real browser behave differently from this page for a short while.

Implemented from the Fetch Standard as last updated 21 September 2026 and the MIME Sniffing Standard as last updated 17 July 2026. This is an independent tool, not affiliated with or endorsed by the WHATWG, any browser vendor, or MDN.