What is a preflight request?

The browser sends an OPTIONS request before the "real" one, asking the server if your method and headers are allowed. Preflights are triggered by any non-"simple" request: PUT, DELETE, PATCH, custom headers, Content-Type other than form-urlencoded/multipart/plain.

Not from the browser. It is a security feature that protects the user from malicious sites. From a server (backend) there are no CORS restrictions, so you can build a small proxy endpoint your frontend calls. Never disable the browser CORS check via flags in production.

Why does curl work but fetch() fail?

CORS only applies in the browser. curl, Postman and server-to-server calls ignore CORS headers entirely. If curl works but fetch() fails, the reason is almost always that the server is missing Access-Control-Allow-Origin for your frontend.

What are "credentials"?

Cookies, HTTP basic auth and TLS client certificates. If the frontend includes credentials (fetch with credentials: "include"), the server must return Access-Control-Allow-Credentials: true AND specify an exact origin (no wildcard *). Otherwise the browser blocks.

CORS Tester - Check Cross-Origin Permissions

How the test works

The tool sends a real request to the URL using fetch() with mode “cors”. If the browser allows the response, cross-origin access is open for that method. If it is blocked, fetch() throws an error.

Note: the browser hides the actual CORS headers (such as Access-Control-Allow-Origin) from JavaScript for security reasons. The test therefore infers permission from whether the request succeeds, rather than reading the header directly. For non-simple methods (PUT/DELETE/PATCH) a preflight (OPTIONS) is triggered automatically by the browser.

About this tool

The CORS tester helps you see whether an API allows your browser to talk to it directly from another domain. CORS (Cross-Origin Resource Sharing) is the security mechanism that keeps a page on example.com from reading data at bank.com without bank.com’s consent. The tool sends a preflight OPTIONS request followed by the real request, shows every Access-Control header the server returns, and explains why a CORS block happens. Useful for API developers configuring headers and for frontend developers diagnosing the dreaded "CORS error" in the console.

How to use it

Paste the URL of the API endpoint you want to test.
Pick the HTTP method (GET, POST, PUT, etc.) and add any custom headers.
Click "Test" to send both the preflight and the real request.
Read the returned Access-Control headers and any error messages.

Examples

Open API

InputGET https://api.example.com/v1/users

Output

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Status: 200 OK (allowed from every origin)

API that blocks

InputPOST https://api.privat.no/checkout

Output

(preflight answers 200, but Access-Control-Allow-Origin is missing)
Result: blocked by the browser, CORS error.

Without Access-Control-Allow-Origin the browser blocks the response even if the server returned 200. The server must be configured to allow your origin.

Common use cases

Verify that your API allows calls from the frontend domain.
Diagnose "CORS error" in production without shipping new code.
Check if a third-party API you’re considering supports direct browser calls.
Test new Access-Control headers after a server config change.
Teach junior devs what a preflight actually does.

Frequently asked questions

What is a preflight request?: The browser sends an OPTIONS request before the "real" one, asking the server if your method and headers are allowed. Preflights are triggered by any non-"simple" request: PUT, DELETE, PATCH, custom headers, Content-Type other than form-urlencoded/multipart/plain.
Can I bypass CORS?: Not from the browser. It is a security feature that protects the user from malicious sites. From a server (backend) there are no CORS restrictions, so you can build a small proxy endpoint your frontend calls. Never disable the browser CORS check via flags in production.
Why does curl work but fetch() fail?: CORS only applies in the browser. curl, Postman and server-to-server calls ignore CORS headers entirely. If curl works but fetch() fails, the reason is almost always that the server is missing Access-Control-Allow-Origin for your frontend.
What are "credentials"?: Cookies, HTTP basic auth and TLS client certificates. If the frontend includes credentials (fetch with credentials: "include"), the server must return Access-Control-Allow-Credentials: true AND specify an exact origin (no wildcard *). Otherwise the browser blocks.

Technical background

CORS is defined in the Fetch standard (fetch.spec.whatwg.org). It builds on the same-origin policy: a page may read responses from the same protocol/host/port combination it was loaded from. Everything else is cross-origin and needs explicit permission via Access-Control headers. Simple requests (GET/HEAD/POST with form content types) go straight through, and the browser checks Access-Control-Allow-Origin in the response before letting JavaScript read it. Complex requests trigger a preflight OPTIONS asking "may I send PATCH with Content-Type: application/json and an X-Trace-Id header?". The server replies with Allow-Methods, Allow-Headers and Max-Age (how long the browser may cache the preflight, typically 600s). Beware of Allow-Origin: * : you can’t use credentials with it, and every domain on the internet can read your responses. Best practice for APIs is to echo back the request’s Origin header if it’s in a whitelist, along with Access-Control-Allow-Credentials: true only when auth is needed.