CORS Header Generator

Generate Nginx / Apache CORS config and a matching fetch() example from your settings.

The CORS Header Generator produces the exact server configuration you need to allow cross origin requests, along with a matching fetch example you can use on the client side. You choose which origins, methods, and headers to allow, and whether credentials are involved, and it writes out the Nginx or Apache rules that satisfy the browser. It also flags the common trap that a wildcard origin cannot be combined with credentials, in which case you must echo back the specific requesting origin instead. Use it to stop guessing at the header list and to get a working, copyable config in one step. Allowing cross origin requests is a matter of the server sending the right headers, and the set of headers is small enough to write from memory but specific enough that a mistake produces an error indistinguishable from a missing configuration. The tool produces the exact rules for a chosen set of origins, methods, and headers, along with whether credentials are involved, in the form a web server actually expects, so the change can be applied and tested rather than guessed at. The one trap worth calling out is the interaction with credentials. A wildcard origin cannot be combined with credential support, because allowing any origin to send authenticated requests would defeat the same origin policy entirely, so the server must echo back the specific requesting origin instead. The counterpart headers matter too, since a preflight request asks which methods and headers are permitted and the server has to answer that exchange before the real request is allowed. Producing both the configuration and a matching client side example makes it possible to verify the setup end to end.

Private by design. Every tool runs 100% in your browser — your code, text, and tokens never leave your device. Nothing is uploaded or stored.
If Allow-Credentials is true, Allow-Origin must be the exact origin (not *). Copy the block into your server config.
Nginx
location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
    add_header 'Access-Control-Max-Age' '600' always;
    if ($request_method = 'OPTIONS') { return 204; }
}
Apache
<IfModule mod_headers.c>
    Header always set Access-Control-Allow-Origin "https://app.example.com"
    Header always set Access-Control-Allow-Methods "GET, POST"
    Header always set Access-Control-Allow-Headers "Content-Type, Authorization"
    Header always set Access-Control-Max-Age "600"
</IfModule>
Browser fetch
fetch('https://api.example.com/data', {
  method: 'GET',
  headers: { 'Content-Type': 'application/json' },
  credentials: 'omit'
});

Frequently Asked Questions

When do I need Access-Control-Allow-Credentials?

Only when the request sends cookies or HTTP auth. If you set credentials: include on the client, the server must echo Allow-Credentials: true and cannot use a wildcard origin.

Why is a wildcard origin rejected with credentials?

For security, a * origin cannot be combined with credentialed requests. You must echo back the exact requesting origin instead of the wildcard.

Do preflight OPTIONS requests need these headers too?

Yes. The browser sends an OPTIONS preflight first; your server must answer it with the CORS headers and a 204, or the actual request is never sent.

Related tools from our network

A focused set of free calculators and guides across related topics — no account required.