CORS Configuration Check

Check a URL's CORS (Access-Control-Allow-*) headers via preflight.

The CORS Configuration Check sends real requests to a URL to see whether it allows browser requests from another origin. It surfaces the server's Access-Control-Allow-Origin, -Methods, -Headers and -Credentials response headers verbatim and grades what they mean as normal, caution, or risky. It's the fastest way to narrow down the cause of the “has been blocked by CORS policy” error you see when calling an API from JavaScript.

Enter the API URL to check and the origin you'd send the request from. The server issues a simple GET request and an OPTIONS preflight request and collects the response headers. Leave the origin blank to test with the default https://example.com. Headers are read server-side rather than in a browser, so no actual data is fetched, and results are briefly cached for speed.

API URLe.g. https://api.example.com/data (reads headers only, no data is fetched)

Origin (optional)Leave blank to test with https://example.com.

How CORS works

When JavaScript makes a request to an origin different from its own, the browser only hands the response back to the script if the response carries the right Access-Control headers. If they're missing or the origin doesn't match, the network response may arrive but the browser blocks the script from reading it.

Access-Control-Allow-Origin: the origin allowed — a specific URL, a wildcard (*), or the requesting origin reflected back.
Access-Control-Allow-Methods: HTTP methods permitted by the preflight.
Access-Control-Allow-Headers: custom request headers that are allowed.
Access-Control-Allow-Credentials: whether cookies and auth credentials may be sent along.

Preflight vs. simple requests

Simple requests like GET are sent directly, but requests with custom headers or methods like PUT and DELETE trigger an OPTIONS preflight first, where the browser asks whether the call is allowed. This tool sends both, evaluating the preflight response headers first and falling back to the simple response when they're absent.

The danger of * with credentials

A configuration that sets Access-Control-Allow-Origin to * (wildcard) while also allowing credentials is dangerous. The spec forbids combining a wildcard with credentials, but a server that blindly reflects the request origin and still allows credentials effectively lets any site call your API using the user's cookies. Only allow trusted origins explicitly. To inspect the rest of the response headers beyond CORS, view the full set with the HTTP header checker.

Frequently asked questions

What should I put for origin?

Use the origin of the website that calls the API. For example, if your frontend is https://app.example.com, enter that to check whether the origin is allowed. Leave it blank to test with https://example.com.

What does an empty Allow-Origin mean?

It means the response has no Access-Control-Allow-Origin header, so the browser blocks JavaScript on that origin from reading the response. In other words, the cross-origin request is not allowed.

Why is * plus credentials risky?

Allowing every origin while also permitting cookies and tokens lets a malicious site call your API with the logged-in user's credentials. APIs that need credentials should allow only specific trusted origins.

Does it fetch the URL's data?

No. The server reads headers only and does not read the response body; it returns just the collected CORS headers. Results are cached for 60 seconds.

Is it fine if headers appear only on the preflight (OPTIONS) and not on GET?

It can be. Browsers send a preflight only for requests with custom headers or methods, not for simple requests like GET, and the server returns Access-Control-Allow-Methods/Headers on that preflight response. The actual request response often only needs Allow-Origin, so judge by looking at both responses together.

Related tools

HTTP / API →

cURL Command Builder

Build a runnable cURL command from method, headers and body.

cURL Command Parser

Break a cURL command into method, URL, headers and body.

Latency Percentile Calculator

Compute p50, p90, p95 and p99 from a list of response times.

HTTP Header Checker

Fetch and display the HTTP response headers of a URL.

HTTP Status & Redirect Checker

Trace the HTTP status code and full redirect chain step by step.

HTTP/2 & HTTP/3 Check

Check whether a server supports HTTP/2 (ALPN) and HTTP/3 (Alt-Svc).