CORS Header Builder and Explainer
Say which sites may call your API, with which methods and headers, and see the exact response headers. Then test a request to see whether the browser will ask first.
Will a browser ask first?
Worked examples
One front end calling an API with cookies
Site: https://app.example.com. Methods: GET, POST. Headers: Content-Type, Authorization. Cookies: yes. Cache: 600 seconds.
Access-Control-Allow-Origin: https://app.example.com, Vary: Origin, Access-Control-Allow-Credentials: true, Access-Control-Allow-Methods: GET, POST, Access-Control-Allow-Headers: Content-Type, Authorization, Access-Control-Max-Age: 600
A JSON POST with an Authorization header needs this preflight answer.
About CORS Header Builder and Explainer
Browsers stop a page on one site from reading the response from another site, unless that other site says it is allowed. The permission is given with CORS headers, and getting them wrong is one of the most common causes of errors that say a request was blocked by the browser. The rules are fiddly: you cannot use a wildcard together with cookies, a response can name only one site, and some requests make the browser ask permission first.
This tool does both halves. In the first half you list the sites that may call your API, tick whether cookies are involved and set the methods, headers and cache time, and it writes the headers for the preflight answer and for the real response, with warnings about combinations that the browser refuses. In the second half you enter the method, headers and content type of a request, and it tells you whether the browser will send a preflight first and why, so you know what your server has to answer.
How to use CORS Header Builder and Explainer
- Enter the sites that may call your API, one per line, or tick Allow any site.
- Set the methods and headers that the calls use, and whether cookies are sent.
- Copy the headers for the preflight answer and for the real response into your server code.
- Use the explainer to test a request and confirm whether a preflight happens.
Common uses
- Fixing a blocked by CORS error in the browser console
- Setting up an API that a separate front end calls
- Checking why an extra OPTIONS request appears
- Reviewing headers before opening an API to partners
Frequently asked questions
What is a preflight request?
Before some cross-site requests the browser sends a small OPTIONS request asking whether the real one is allowed. Your server must answer with the right headers, and only then does the browser send the real request. Requests with other methods, extra headers or a JSON content type need one.
Why can't I use * with cookies?
When cookies or sign-in details are included, the browser insists on a named site. A wildcard in that case is rejected. This tool warns you and leaves the credentials header out when you choose any site.
How do I allow more than one site?
A response can name only one. Your code compares the Origin header of the request with your list and sends back the one that matches, and the Vary: Origin header stops caches mixing up answers.
Why is Authorization still blocked when I allow *?
The wildcard in the allowed headers does not cover the Authorization header. List it by name.
Does CORS protect my API?
No. It only controls what other websites can read in a browser. Tools and servers ignore it completely, so your API still needs its own sign-in and checks.