CORS Request Tester

Send a real cross-origin request from your browser to any API to see if CORS allows it. Explains when a preflight is needed and shows readable headers.

This is a "simple" request: no preflight is needed, but the response is only readable if it carries an Access-Control-Allow-Origin header that matches this site.
The request is sent directly from your browser with the origin of this page (https://algokit.dev), exactly like a script on a website would. Only CORS-safelisted headers and those listed in Access-Control-Expose-Headers are visible.

What is CORS Tester?

This CORS tester sends a genuine cross-origin request from your browser – with the method, Content-Type, custom header and credentials mode you choose – and reports whether the browser lets JavaScript read the response. Before you send, it explains whether the request is "simple" or needs an OPTIONS preflight and why.

How to use CORS Tester

  1. Enter the API URL to test.
  2. Choose the method, an optional Content-Type and an optional custom header such as Authorization: Bearer x.
  3. Tick "Send cookies / credentials" if your app uses credentials: include.
  4. Read the preflight explanation, then press Send test request.
  5. If allowed, review the status and the headers JavaScript can see; if blocked, check the browser console for the exact CORS error.

When to use CORS Tester

Use it to check whether a public API can be called from a browser app, or to reproduce a CORS error with specific headers. The origin is always https://algokit.dev, so a server that only allows your own domain will correctly appear blocked; test from your own site for an exact match. It cannot tell CORS failures apart from network or TLS errors – the browser does not reveal that.

How CORS Tester works

The tool calls fetch() with mode: "cors" from the page's origin (https://algokit.dev), exactly like your own front-end code would. The preflight explanation follows the Fetch standard: methods other than GET/HEAD/POST, a Content-Type other than form-urlencoded, multipart/form-data or text/plain, or any custom header trigger an OPTIONS preflight. When the browser blocks a response it throws a generic TypeError and deliberately hides the reason, so the tool tells you to look at the console.

Common Use Cases

  • Check if a third-party API sends Access-Control-Allow-Origin before integrating it in a SPA.
  • Find out which header in your request triggers a preflight.
  • Verify that credentials: include works (requires a specific origin, not *).
  • See which response headers are exposed to JavaScript via Access-Control-Expose-Headers.

Security Note

The request goes directly from your browser to the URL you enter; with credentials enabled your cookies for that site are sent too.

FAQs

Why does curl work but the browser fails?

CORS is enforced only by browsers. curl and servers ignore it, so an API can work from curl and still be unreadable from a web page.

What triggers a preflight?

A method other than GET, HEAD or POST, a non-simple Content-Type such as application/json, or any custom request header like Authorization.

Can Access-Control-Allow-Origin: * be used with cookies?

No. With credentials the server must echo the exact origin and send Access-Control-Allow-Credentials: true.

Explore more categories