CORS Tester

Test CORS headers and cross-origin resource sharing policies. Free, fast, and works entirely in your browser with no sign-up required.

Updated

Share:
Home/Website Tools/CORS Tester & Debugger

CORS Tester & Debugger

Test CORS headers for any API endpoint and debug cross-origin issues.

CORS Tester

Frequently Asked Questions

Why does my browser say 'blocked by CORS policy' even though the API works in Postman?

Postman and curl are not browsers, so they ignore the same-origin policy entirely — they send the request and read the response no matter what headers come back. A browser is stricter: when JavaScript on one origin calls a different scheme, domain, or port, it only lets your code read the response if the server returns the right Access-Control-Allow-Origin header. If that header is missing, the request still reaches the server and returns data, but the browser hides the response from your script and logs the CORS error. That is why an endpoint can look healthy in Postman yet fail in the console. This tool inspects the actual CORS headers a server sends back, so you can confirm the problem is server-side configuration rather than your fetch code. Paste your endpoint to see exactly which headers are present.

What is a CORS preflight request and when does the browser send one?

A preflight is an automatic OPTIONS request the browser sends before the real request, asking the server whether the actual call is allowed. It happens for "non-simple" requests: methods like PUT, DELETE, or PATCH, custom request headers, or content types such as application/json. The browser includes Access-Control-Request-Method and Access-Control-Request-Headers, and the server must answer with matching Access-Control-Allow-Methods and Access-Control-Allow-Headers values, or the real request never fires. Simple GET and POST requests with standard headers skip this step. Because preflights are invisible in most fetch code, a failing OPTIONS handshake is a common and confusing cause of CORS errors. This tester lets you send the request as OPTIONS and inspect the allowed methods and headers the server reports, so you can verify the preflight contract directly instead of guessing from a blocked console message.

Why does Access-Control-Allow-Credentials fail when the origin is a wildcard?

The CORS specification forbids combining credentialed requests with a wildcard origin, and every browser enforces this. When you send cookies or authorization headers cross-origin, the server must echo back a specific origin in Access-Control-Allow-Origin — never the catch-all asterisk. If a server responds with both Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin set to a wildcard, the browser rejects the response outright and your request fails, even though the headers look permissive. The fix is to reflect the exact requesting origin instead of using a wildcard, then keep the credentials header set to true. This tool flags that exact dangerous combination as an error in its CORS analysis, so you can catch it before it breaks an authenticated front-end. Run your credentialed endpoint through it to confirm the origin is specific rather than wildcarded.

Is a wildcard Access-Control-Allow-Origin (*) safe to use?

A wildcard origin lets any website on the internet make cross-origin requests to your API and read the response, which is perfectly fine for genuinely public data like open datasets, public read-only APIs, or static JSON. It becomes risky the moment the endpoint returns anything sensitive or is reachable with a user's cookies, because a malicious site could then call it on a visitor's behalf. As a rule, restrict Access-Control-Allow-Origin to the specific domains that legitimately need access rather than opening it to everyone, and never pair a wildcard with credentials. This tester labels a wildcard origin as a warning and a specific domain as good, so you can see at a glance how exposed an endpoint is. Test your URL here to check whether its origin policy matches the sensitivity of the data it serves.

What does the Access-Control-Max-Age header do for CORS performance?

Access-Control-Max-Age tells the browser how many seconds it may cache the result of a preflight OPTIONS request. While that cache is valid, the browser skips the extra round trip and sends the real request straight away, which noticeably speeds up apps that fire many non-simple requests to the same endpoint. Without it, the browser may re-preflight on every call, adding latency. Values are capped by the browser — Chrome limits the cache to a couple of hours regardless of a higher number — so setting an enormous value will not help beyond that ceiling. A missing Max-Age simply means no preflight caching at all. This tool reads the header and translates the raw seconds into minutes in its analysis, so you can quickly judge how aggressively preflights are cached. Test your endpoint to see whether it sets a useful Max-Age.

About the CORS Tester

The CORS Tester checks how any API endpoint responds to cross-origin requests, so you can see exactly which Cross-Origin Resource Sharing headers a server sends back and why a browser is blocking your front-end. Enter a URL, pick an HTTP method, and the tool fetches the endpoint and reports the status code, the CORS-relevant headers, the full response header set, and the first part of the response body. It is built for front-end developers, API engineers, and anyone debugging the "blocked by CORS policy" error that shows up in the browser console.

Because a browser will not let a page read a raw cross-origin response, the tool sends your request through a public proxy (corsproxy.io) and inspects the headers that come back. That means the request does leave your device — so test public or staging endpoints rather than pasting private credentials you would not want a third party to see. There is no sign-up, account, or install required to use it.

What the CORS Tester checks

The tool reads and explains the standard CORS response headers:

  • Access-Control-Allow-Origin — which origin(s) the server permits. The tool flags whether CORS is configured at all, and whether the value is a specific domain or a wildcard.
  • Access-Control-Allow-Methods — the HTTP verbs the endpoint accepts cross-origin.
  • Access-Control-Allow-Headers — the request headers the server will accept on a preflighted request.
  • Access-Control-Allow-Credentials — whether cookies and authorization headers are allowed.
  • Access-Control-Max-Age — how long, in seconds, the browser may cache the preflight result.
  • Access-Control-Expose-Headers — which response headers your JavaScript is allowed to read.

You can send the request as GET, POST, PUT, DELETE, OPTIONS, or PATCH, add any custom request headers as key-value pairs, and attach a JSON request body for POST, PUT, and PATCH. Results are split across three views: a plain-language CORS Analysis, the complete Response Headers list (copyable), and the Response Body.

Reading the analysis

Each finding is labelled good, warning, error, or informational so you can scan results quickly:

  • A missing Access-Control-Allow-Origin header is flagged as an error — the server has no CORS configured, so browsers will block reads.
  • A wildcard origin (*) is flagged as a warning, because it lets any site call the API. That is fine for fully public data but risky for anything sensitive.
  • The combination of Access-Control-Allow-Credentials: true with a wildcard origin is flagged as an error, because the specification forbids it and browsers reject it outright. Credentialed requests require an explicit origin.
  • A Max-Age value is translated into minutes so you can see how aggressively preflight responses are cached.

Why CORS testing matters

CORS is a browser security mechanism: by default, JavaScript on one origin cannot read responses from a different origin (a different scheme, domain, or port). For "non-simple" requests — custom headers, JSON content types, or methods like PUT and DELETE — the browser first sends an OPTIONS preflight, and the real request only proceeds if the server answers with the right headers. When that handshake fails, the request is blocked before your code ever sees the data, which is why CORS errors are so common when wiring a single-page app to a separate API or a third-party service.

Testing the endpoint directly tells you whether the problem is on the server (missing or misconfigured headers) rather than in your fetch code. When no CORS headers are detected, the CORS Tester also shows ready-to-paste configuration snippets for Express.js and Node, Nginx, and Apache .htaccess, so you can fix the origin and methods on the server and re-test. Paste an endpoint above to see how it responds and get a clear read on its cross-origin policy.