Web Tools

CORS Checker

Check the CORS headers on any URL. See if cross-origin requests are allowed and from which origins.

Server-assisted public lookup

CORS Headers

Results are fetched from our server, not your browser.

Next useful step

Related tools

5 selected

01 Dmarc Checker Continue with a nearby task 02 Dns Checker Continue with a nearby task 03 Mx Checker Continue with a nearby task 04 Spf Checker Continue with a nearby task 05 Whois Lookup Continue with a nearby task

What is the Cors Checker?

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls which web origins are permitted to make requests to a given server. Misconfigured CORS headers are a frequent source of both security vulnerabilities (overly permissive) and development frustration (overly restrictive). This tool tests a URL's CORS configuration by sending preflight and actual cross-origin requests and analyzing the response headers for correctness.

How to use the Cors Checker

  1. Enter the API or resource URL you want to test.
  2. Enter the origin you want to test from (e.g., your frontend domain, https://app.example.com).
  3. Select the HTTP method (GET, POST, PUT, DELETE) and add any custom request headers if relevant.
  4. Click Test CORS to send a preflight OPTIONS request and the actual request, then inspect the results.
  5. Review which headers are present, whether the origin is allowed, and whether credentials are supported.

Frequently asked questions

CORS is enforced by the browser, not the server. Server-to-server requests (curl, backend code, API clients) are not subject to CORS restrictions - only browser-initiated cross-origin JavaScript requests are blocked.
Before sending a cross-origin request with a non-simple method (PUT, DELETE, PATCH) or custom headers, browsers send a preflight OPTIONS request to ask the server if the actual request is permitted. The server must respond with appropriate Access-Control-Allow-* headers.
For truly public APIs with no authentication, a wildcard origin is fine. However, for APIs that use cookies or HTTP authentication, a wildcard cannot be used with Access-Control-Allow-Credentials: true. Always use the most restrictive origin allowlist that your use case permits.