CORS Header Generator
Visually configure CORS headers and get copy-paste-ready configuration for Nginx, Apache, and Express.js.
How ZeroData protects your privacy
- ✓ No Uploads: Processing happens entirely via client-side JavaScript.
- ✓ No Storage: We do not have a database. We physically cannot save your data.
- ✓ No Tracking: We don't log what you process or track your inputs.
- ✓ Verifiable: Check your DevTools Network tab. You will see 0 outbound requests.
Stop Guessing CORS Headers
Generating the correct Access-Control-Allow-Origin headers is one of the most frustrating aspects of modern web development. Whether you are building a decoupled frontend architecture, setting up microservices, or creating a public API, misconfiguring CORS will instantly break your application in the browser. Before deploying your new configuration, you should verify it using our CORS Tester or analyze your existing server responses with the HTTP Header Analyzer.
The core issue is that every web server and framework handles CORS slightly differently. A single typo in an Nginx add_header directive or a missed OPTIONS preflight handler in Express.js leads to the dreaded "Access to XMLHttpRequest has been blocked by CORS policy" error. This CORS Header Generator provides a visual interface to select your origins, methods, and credentials, instantly translating them into production-ready configuration code for Nginx, Apache, Express, and raw HTTP headers.
Quick Solution: The "Allow All" Baseline
If you are building a completely public API with no authentication required, this is the quickest way to allow all cross-origin requests. (Warning: Do not use this if your API uses cookies or authorization headers).
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type Production CORS Examples
Here is how CORS headers are correctly applied in the most common web servers and frameworks.
1. Nginx CORS Configuration
In Nginx, CORS headers are typically added within a location block. It is critical to handle the OPTIONS preflight request by returning a 204 No Content status immediately.
location /api/ {
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
} 2. Express.js (Node.js) Middleware
For Node.js backends, installing the standard cors package is the most robust solution. Here is how to configure it to allow a specific frontend origin while supporting credentials.
const express = require('express');
const cors = require('cors');
const app = express();
const corsOptions = {
origin: 'https://my-frontend.example.com',
methods: 'GET,POST,PUT,DELETE',
allowedHeaders: ['Content-Type', 'Authorization'],
credentials: true,
optionsSuccessStatus: 204
};
app.use(cors(corsOptions));
app.get('/api/data', (req, res) => {
res.json({ message: 'CORS is configured correctly!' });
}); 3. Apache (.htaccess)
If you are running an Apache server, you can configure CORS directly in your .htaccess file using the Header directive. Ensure that the mod_headers module is enabled.
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept, Authorization"
</IfModule> Troubleshooting CORS Preflight Failures
If your CORS headers are seemingly correct but requests still fail, the issue is almost certainly related to the preflight request. Browsers send an automatic HTTP OPTIONS request before sending requests that use custom headers (like Authorization) or methods other than GET/POST.
To resolve preflight failures:
- Ensure your server actively routes and responds to the
OPTIONSmethod. - Verify the preflight response returns a successful HTTP status code (typically
204or200). - Check that the preflight response includes the required
Access-Control-Allow-MethodsandAccess-Control-Allow-Headers. - If using credentials, ensure
Access-Control-Allow-Originis set to the exact requesting domain, not a wildcard (*).
Common Use Cases
- Configuring CORS headers for a new REST API that serves a React/Vue/Angular frontend.
- Fixing 'Access to XMLHttpRequest has been blocked by CORS policy' errors.
- Setting up Nginx reverse proxy CORS headers for a microservices architecture.
- Generating Apache .htaccess rules for cross-origin resource sharing.
- Adding CORS middleware to an Express.js or Node.js backend.
Frequently Asked Questions
What is CORS and why do I need it?
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that blocks web pages from making requests to a different domain than the one that served the page. If your frontend (e.g., app.example.com) calls an API on api.example.com, the API server must include CORS headers to allow the request.
What does Access-Control-Allow-Origin: * mean?
The wildcard (*) means any website in the world can call your API. This is fine for public APIs with no authentication, but dangerous for private APIs. If you use credentials (cookies/tokens), you MUST specify exact origins instead of *.
Why do I see a preflight OPTIONS request?
Browsers send a 'preflight' OPTIONS request before certain cross-origin requests (those with custom headers, PUT/DELETE methods, etc.) to check if the server allows it. Your server must respond to OPTIONS requests with the correct CORS headers and a 204 status code.
Can I use Allow-Credentials with wildcard origin?
No. Browsers explicitly block Access-Control-Allow-Credentials: true when the origin is set to *. You must specify the exact origin domain(s) when using credentials.
How do I fix the 'No Access-Control-Allow-Origin header is present on the requested resource' error?
This error means your server is not returning the required CORS headers. You need to configure your web server (like Nginx or Apache) or your backend framework (like Express or Django) to return the Access-Control-Allow-Origin header in the response.
What should I set Access-Control-Allow-Methods to?
You should list only the HTTP methods your API actually supports, such as GET, POST, PUT, and DELETE. Restricting allowed methods improves security by preventing unexpected request types.
Are CORS headers applied on the client or server?
CORS headers must be generated and applied on the server. The browser enforces the CORS policy by checking the headers returned by the server. If the server doesn't send the correct headers, the browser will block the frontend JavaScript from accessing the response.
Related Tools
HTTP Header Analyzer
Parse and analyze HTTP response headers for security issues. Check CSP, HSTS, and more — locally in your browser.
Docker Run to Compose Converter
Convert docker run commands into docker-compose.yml files instantly. Runs completely locally in your browser.
Chmod Calculator
Visual Linux file permissions calculator with numeric mode, symbolic notation, and common presets.
CORS Tester
Test CORS headers on any API endpoint directly from your browser. Simulate cross-origin requests and get fix recommendations.
Nginx Config Generator
Generate Nginx server block configurations visually. Reverse proxy, SSL, gzip, and security headers — 100% browser-based.
Security Headers Builder
Generate HTTP security response headers for Nginx, Apache, Express, Caddy, and Cloudflare Workers.