CORS Tester

Server assisted Web

Check whether an API allows a specific origin, method and headers. The tool issues OPTIONS and actual requests through a safe server-side checker and explains why the browser would allow or block the call.

Privacy: Processing happens in your browser where possible. Network checks are relayed through the Mutqan backend and are not stored.

How to use CORS Tester

  1. Enter the public API URL and the origin of the web app that will call it.
  2. Select the method and list the request headers the app will send (Authorization, Content-Type…).
  3. Run the test and read the verdict; the "Why" list names the exact header that would block the browser.
  4. Fix the server configuration and re-run until the verdict is Allowed.

CORS Tester features

  • Sends a preflight (OPTIONS) and the actual request with your chosen Origin, method and request headers
  • Verdict explained step by step: origin match, credentials, allowed methods and headers, preflight status, max-age
  • Detects when a preflight is required using the CORS-safelisted rules
  • Tables of preflight and actual response headers with explanations
  • Warns about wildcard-with-credentials, missing Vary: Origin and "null" origins

CORS Tester example

Test a credentialed POST

Input:

URL: https://api.example.com/v1/orders · Origin: https://app.example.com · Method: POST · Headers: Authorization, Content-Type

Output:

Result: Blocked
Preflight needed: Yes (OPTIONS) · Preflight status: 204
Access-Control-Allow-Origin is "*" but the request is credentialed; browsers reject the wildcard with credentials.
Access-Control-Allow-Headers does not list: Authorization.

Frequently asked questions about CORS Tester

When does a browser send a preflight?

For any method other than GET, HEAD or POST, for request headers outside the CORS-safelisted set (Accept, Accept-Language, Content-Language, Content-Type with form/text values) and for Content-Type values such as application/json. The tool tells you whether your combination triggers OPTIONS.

Why is my request blocked even though Access-Control-Allow-Origin is *?

A wildcard is rejected when the request uses credentials (cookies or Authorization with credentials: "include"). Echo the exact origin, add Access-Control-Allow-Credentials: true and Vary: Origin instead.

Why does the tool call the API from a server instead of my browser?

A browser hides the blocked response, so you would only see a generic error. The relay performs the OPTIONS and actual requests with the Origin header you chose and returns the raw Access-Control-* headers so the verdict can be explained.

Can I test localhost or an internal API?

No. The relay refuses private, loopback and link-local addresses for safety. Expose the API through a tunnel (e.g. a public staging host) to test it.

Technical notes

The relay reproduces the browser algorithm from the Fetch Standard: the preflight is sent with Access-Control-Request-Method and Access-Control-Request-Headers, and the actual request with the Origin header. The server-side verdict is combined with a local re-evaluation so every reason is spelled out, including cases the relay treats as allowed but that fail for credentialed requests.