/

CORS Request Tester

Send a real cross-origin request from your browser to any public endpoint and see whether CORS allows it — including the Access-Control-Allow-* response headers.

Request
Endpoint URL
Method
Request headers (comma-separated)Adding custom headers or a non-simple method triggers a preflight OPTIONS request.
The request comes from . The browser enforces CORS, so a blocked request behaves exactly as it would in your own app.
Result
Enter an endpoint and click Send request.

Bookmark this tool now — skip the search next time you need it.

About CORS Request Tester

Send a real cross-origin request from your browser to a public endpoint and see whether CORS actually allows it, along with the Access-Control-Allow-* headers that decided the outcome. CORS failures are frustrating precisely because the browser console tells you a request was blocked without telling you which header was missing or mismatched — and the request itself often succeeded on the server, so your logs look fine. This runs the real thing from a real browser origin and shows you the response headers, which is where the answer always is. Note that unlike most tools here, this one does make a live network request to the URL you enter.

Key features

  • Sends a genuine cross-origin request from your browser, not a simulation
  • All seven common methods: GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS
  • Custom request headers, which is what triggers a preflight
  • Reports the Access-Control-Allow-Origin, -Methods, -Headers, and -Credentials response headers
  • Distinguishes a CORS block from an ordinary network or server failure
  • Shows the response status when the request is allowed through
  • Copyable header list for pasting into a bug report
  • No backend of ours involved — the request goes from your browser straight to the endpoint

How to use it

  1. Enter the endpoint URL you want to test.
  2. Choose the HTTP method.
  3. List any custom request headers, comma separated.
  4. Send, then read the Access-Control-Allow-* headers in the result.

Tips & common mistakes

  • This tool makes a real request to the URL you enter. Point it at endpoints you own or public APIs — not at something that will charge money or mutate data.
  • Adding a custom header is what turns a simple request into a preflighted one. The browser sends an OPTIONS request first, and the server must answer that too — a server handling only GET will fail here.
  • Access-Control-Allow-Origin cannot be a wildcard when credentials are involved. With credentials enabled it must name your exact origin, which is the most common misconfiguration.
  • Only a handful of response headers are readable from JavaScript by default. To expose others, the server must list them in Access-Control-Expose-Headers.
  • CORS is enforced by the browser, not the server. The request usually reaches the server and succeeds there — which is why server logs show a 200 for a call your JavaScript never got to read.
  • A failure with no CORS headers at all usually means the server has no CORS configuration, rather than a wrong one. Those are different fixes.
  • CORS is not a security control protecting your API. It governs what other origins may read in a browser; it does nothing about requests from curl or a server.
  • To inspect any response’s headers in detail, not just the CORS ones, use the HTTP Header Analyzer.

Related tools

Browse all 8 Security tools

Frequently asked questions

10

Enter the endpoint URL, choose a method, optionally add request headers, and click Send request. The tool fires a real cross-origin request and reports whether the browser allowed it.

The most common cause is the server not returning an Access-Control-Allow-Origin header that permits your origin. Custom headers or non-simple methods also require the server to answer a preflight OPTIONS request.

For requests with custom headers or methods like PUT and DELETE, the browser first sends an OPTIONS request asking the server what it allows. If the server does not approve it, the real request is blocked.

By design, browsers only expose a small set of response headers to JavaScript. The server must list additional ones in Access-Control-Expose-Headers for them to appear.

Yes. The request originates from this page in your browser, so the browser enforces exactly the same CORS rules your own front-end code would encounter.

Yes — it makes a genuine cross-origin request from your browser. Point it at endpoints you own or public APIs, not at anything that charges money or changes data.

A custom header turns a simple request into a preflighted one, so the browser sends an OPTIONS request first. A server that only handles GET will fail that preflight.

CORS is enforced by the browser, not the server. The request usually arrives and succeeds — the browser then refuses to hand the response to your JavaScript.

The spec forbids it. When credentials are involved, Access-Control-Allow-Origin must name your exact origin — this is the most common misconfiguration there is.

No. It governs what other origins may read in a browser and does nothing about requests from curl, a script, or a server. It is not an access control.