CORS Header Generator
Allow the right websites to call your API from the browser. List the origins, methods and headers, decide about cookies, and get configuration for your server that answers preflight requests, echoes only allowed origins (even several of them), sets Vary: Origin and never combines a wildcard with credentials.
- Runs in your browser
- No sign-up
- Free to use
How to use CORS Header Generator
- Choose specific websites or any website.
- List the origins, methods and request headers your front end uses.
- Turn on credentials only if the browser must send cookies.
- Pick the server or platform and paste the result into its configuration.
CORS Header Generator features
Several origins
Generates origin checks, because the header can only hold one origin.
Preflight handling
Answers OPTIONS requests with 204 and the right headers.
Credential safety
Refuses the invalid * plus credentials combination.
Validation
Checks origins and header names and explains mistakes.
Server code
Apache, Nginx, IIS CORS module, Express, PHP and static hosts.
Plain explanations
Notes on cookies, preflight caching and what CORS does not protect.
When to use CORS Header Generator
- Letting a React, Vue or Angular app on another domain call your API.
- Fixing “No Access-Control-Allow-Origin header is present” errors.
- Publishing a public read-only JSON API.
- Allowing both a production and an admin front end with cookies.
CORS Header Generator FAQ
What is CORS?
Cross-Origin Resource Sharing is how a server tells the browser that pages from other origins may read its responses. Without it, the browser blocks JavaScript on site A from reading data fetched from site B.
Why can I not list several origins in the header?
Access-Control-Allow-Origin holds exactly one origin or *. To allow several, the server compares the request’s Origin header with a list and echoes it back when it matches, which is what the generated code does.
Why does * not work with cookies?
Browsers refuse credentialed responses that allow every origin, because that would let any site act as the logged-in user. Name the allowed origins instead.
What is a preflight request?
Before a request with a non-simple method or header, such as PUT or a JSON body, the browser sends an OPTIONS request asking for permission. The server must answer it with the CORS headers, usually with status 204.
Does CORS protect my API?
No. It only relaxes the browser’s same-origin rule. Anyone can still call the API from a server or with curl, so authentication and authorisation are still required.
Why add Vary: Origin?
When the response depends on the Origin header, caches must store a separate copy per origin. Without Vary: Origin, a cache could serve one site’s allowed response to another site.
How CORS works
Browsers apply the same-origin policy: a script on one origin (scheme, host and port) cannot read responses from another origin. CORS is the controlled exception. When a page calls an API on another origin, the browser includes an Origin header, and only lets the script read the response if the server answers with a matching Access-Control-Allow-Origin header.
Requests that could change data or that use custom headers trigger a preflight first. The browser sends an OPTIONS request with Access-Control-Request-Method and Access-Control-Request-Headers, and the server replies with the methods and headers it accepts. Only then is the real request sent. Access-Control-Max-Age lets the browser remember the answer for a while, so not every call needs a preflight.
Credentials are a separate decision. By default, cross-origin requests do not carry cookies or HTTP authentication. If the front end uses fetch with credentials: "include", the server must reply with Access-Control-Allow-Credentials: true and name the exact origin; a wildcard is rejected. Cookies used this way must also be marked SameSite=None and Secure.
A common mistake is to reflect whatever Origin the browser sends. That makes the API readable by every website, including malicious ones, with the user’s cookies. The generated code compares the origin with an explicit list and only echoes it on an exact match. The same reason rules out wildcard subdomains, which browsers do not support in the header anyway.
CORS is about what browsers let other sites read; it does not stop requests from being sent or protect data from people calling the API directly. Keep authentication, CSRF protection for cookie-based APIs, and rate limiting in place. If a request still fails after configuring CORS, the browser console names the missing or mismatched header, which usually points to the setting to change.