CORS Header Generator

When Should I Use This?

Use the CORS header generator when you are configuring cross-origin access for an API or web server and need to prevent browsers from blocking requests.

• Allowing a Single Page Application (SPA) on app.example.com to fetch data from an API on api.example.com.
• Configuring AWS API Gateway or S3 buckets to serve web fonts or assets to external domains without triggering No 'Access-Control-Allow-Origin' header is present errors.
• Setting up strict CORS policies that require credentials (cookies or authorization headers) by properly combining Access-Control-Allow-Credentials: true and specific origin domains.

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. If you're configuring security beyond CORS, you can also use our Security Headers Builder. For a deeper understanding, check out our pillar Web Security Complete Guide.

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 & Format Errors

If your CORS headers are seemingly correct but requests still fail, the issue usually falls into one of two categories: Preflight Request Failures or Invalid Header Formatting.

1. Preflight Request Failures

Browsers send an automatic HTTP OPTIONS request before sending requests that use custom headers (like Authorization) or methods other than GET/POST. To resolve these:

• Ensure your server actively routes and responds to the OPTIONS method.
• Verify the preflight response returns a successful HTTP status code (typically 204 No Content or 200 OK).
• Check that the preflight response includes the required Access-Control-Allow-Methods and Access-Control-Allow-Headers.
• If using credentials, ensure Access-Control-Allow-Origin is set to the exact requesting domain, not a wildcard (*).

2. Invalid CORS Header Format

Browsers are extremely strict about how CORS headers are parsed. Common formatting mistakes include:

• Multiple Origins: Access-Control-Allow-Origin must be a single string (or *). You cannot send a comma-separated list like https://a.com, https://b.com. Your server backend must dynamically read the Origin request header, check it against an allowlist, and echo that single origin back in the response.
• Trailing Slashes: The origin https://example.com is NOT the same as https://example.com/. CORS origins must never include a trailing slash or path.
• Duplicate Headers: Sometimes a reverse proxy (like Nginx) adds CORS headers on top of a backend (like Node.js) that also adds them. If the browser sees two Access-Control-Allow-Origin headers in the response, it will instantly fail the request.