Introducing CORS Headers Generator: Fix CORS Errors With the Right Config in Seconds

We shipped a free CORS Headers Generator. Configure your allowed origins, methods, request headers, credentials, and preflight settings visually — then copy ready-to-paste config for Express.js, Nginx, Apache, or raw HTTP. No sign-up. No server. Everything runs in your browser.

→ cors-headers-generator.tools.jagodana.com

What Is CORS and Why Do You Need the Right Headers?

CORS (Cross-Origin Resource Sharing) is the browser security policy that controls which external domains can make requests to your API. When a front-end app on https://app.example.com calls https://api.example.com, the browser checks whether the API's response includes headers that explicitly permit that origin.

Without the right headers, the browser blocks the response:

Access to fetch at 'https://api.example.com' from origin 'https://app.example.com'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

The fix is straightforward in principle — add the correct Access-Control-* headers to your server responses. But the configuration has enough nuance that getting it right the first time is harder than it looks.

Why Is CORS Configuration Error-Prone?

The wildcard + credentials trap

Access-Control-Allow-Origin: * allows requests from any domain. Access-Control-Allow-Credentials: true allows cookies and auth headers to be sent cross-origin. Together, they seem like they'd cover everything — but browsers explicitly reject this combination:

The value of the 'Access-Control-Allow-Origin' header in the response must not be
the wildcard '*' when the request's credentials mode is 'include'.

If you need credentials, you must specify exact origins. Our tool flags this conflict in real time before you paste anything.

Multi-origin allowlists require server logic

Access-Control-Allow-Origin only accepts a single value — you can't list multiple origins separated by commas. If you need to allow both https://app.example.com and https://staging.example.com, you need server code that:

1. Reads the Origin header from the request
2. Checks it against an allowlist
3. Echoes the matching origin back in the response

Our Express.js output generates this allowlist check automatically.

Preflight OPTIONS requests need their own handling

Before sending non-simple requests (anything with Authorization, custom headers, or non-GET/POST methods), browsers send an OPTIONS preflight. Your server must respond to OPTIONS with the correct CORS headers and a 204 status — before the real request is attempted.

If your Nginx config adds Access-Control-Allow-Origin to normal responses but doesn't handle OPTIONS, preflight requests return 405 Method Not Allowed and nothing works.

Different servers need different syntax

The same CORS policy looks completely different across Express.js, Nginx, and Apache:

// Express.js
app.use(cors({ origin: 'https://app.example.com', methods: ['GET', 'POST'] }));

# Nginx
if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST' always;
    return 204;
}
add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;

# 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"
</IfModule>

Each format has its own edge cases. The generator produces correct output for all four.

How Does the CORS Headers Generator Work?

How do I configure multiple allowed origins?

Enter each origin as a separate tag in the Allowed Origins field. Press Enter or comma to add each one. The Express.js output automatically generates the allowlist function:

const allowedOrigins = ['https://app.example.com', 'https://staging.example.com'];
 
const corsOptions = {
  origin: (origin, callback) => {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  // ...
};

The Nginx and Apache outputs use the first origin from your list — for multi-origin Nginx setups, you'll need a map block (described in the Nginx output comments).

What is the Max-Age setting for?

Max-Age sets Access-Control-Max-Age, which tells the browser how long to cache the preflight response. Without it, the browser sends an OPTIONS request before every non-simple request. Set it to 86400 (24 hours) in production to eliminate preflight latency from your API calls. Set it to 0 during development to ensure your CORS changes take effect immediately.

Should I use Access-Control-Allow-Headers: *?

The wildcard for headers (Access-Control-Allow-Headers: *) is supported in modern browsers but not in older Safari versions. For maximum compatibility, explicitly list the headers your API accepts: Content-Type, Authorization, X-API-Key. The generator's suggestions surface the most common ones.

What's the difference between Allowed Headers and Exposed Headers?

Allowed Headers (Access-Control-Allow-Headers) tells the browser which request headers are permitted in cross-origin requests. If you send Authorization without listing it here, the preflight fails.

Exposed Headers (Access-Control-Expose-Headers) controls which response headers are accessible to client-side JavaScript via response.headers.get(). By default, only Cache-Control, Content-Language, Content-Length, Content-Type, Expires, and Last-Modified are accessible. If your API sends X-Total-Count or X-Request-ID in responses and you want your front-end to read them, add them to Exposed Headers.

Common CORS Scenarios and the Config That Fixes Them

React/Vue SPA calling a REST API

Your front-end is at https://app.yourproduct.com. Your API is at https://api.yourproduct.com. You're using JWT tokens in the Authorization header.

Configuration:

• Origin: https://app.yourproduct.com
• Methods: GET, POST, PUT, DELETE, OPTIONS
• Allowed Headers: Content-Type, Authorization
• Credentials: disabled (if using JWTs in headers, not cookies)
• Max-Age: 86400

API with cookie-based sessions

You're using server-side sessions. The browser sends the session cookie with cross-origin requests.

Configuration:

• Origin: https://app.yourproduct.com (exact origin — no wildcard)
• Methods: GET, POST, OPTIONS
• Allowed Headers: Content-Type
• Credentials: enabled
• Max-Age: 3600

You also need withCredentials: true in your fetch/axios config on the front-end.

Multi-environment API (staging + production)

Your API serves both staging (https://staging.yourproduct.com) and production (https://app.yourproduct.com) front-ends.

Configuration:

• Origins: both domains as separate tags
• Methods: GET, POST, PUT, DELETE, OPTIONS
• Allowed Headers: Content-Type, Authorization
• Max-Age: 86400

The Express.js output generates the allowlist logic. For Nginx, you'll implement a map block using the generated header values.

Public read-only API

You're shipping a public API with no authentication. Any website should be able to call it.

Configuration:

• Allow all origins: enabled
• Methods: GET, OPTIONS
• Allowed Headers: Content-Type
• Credentials: disabled
• Max-Age: 86400

What Gets Generated for Each Framework?

Express.js

A complete corsOptions configuration object and the app.use(cors(corsOptions)) call. For multi-origin setups, a full allowlist callback function. Install the cors package, paste, done.

Nginx

An if ($request_method = 'OPTIONS') block with the complete preflight response (204 status, all headers), followed by add_header directives for all other responses. Drop it into your server {} or location {} block.

Apache

<IfModule mod_headers.c> directives for all Access-Control headers, plus a <IfModule mod_rewrite.c> block that returns 204 for OPTIONS requests. Works in .htaccess or VirtualHost config with mod_headers and mod_rewrite enabled.

Raw HTTP

The header names and values as plain text — one header per line. Use this for any language or platform not covered above: Python Flask, Ruby Rack, PHP, Go net/http, serverless functions, or API gateway configuration.

Build Details

Built in approximately 45 minutes as Day N of the 365 Tools Challenge. The tool is a single client-side React component with four pure generator functions — one per output format. All code runs in the browser; no network requests are made.

The configuration state is a typed TypeScript object. Every output format is derived from that state through a synchronous function, so there's no async update latency between changing a setting and seeing the new output.

Open source: github.com/Jagodana-Studio-Private-Limited/cors-headers-generator

Try it now: cors-headers-generator.tools.jagodana.com

Part of the Jagodana 365 Tools Challenge — one free developer tool shipped every day.