CORS Header Generator

Generate Cross-Origin Resource Sharing (CORS) headers for your web server or application.

Configuration
One origin per line

What Is CORS?

CORS (Cross-Origin Resource Sharing) is a security mechanism built into web browsers that controls how web pages from one origin (domain, protocol, and port) can request resources from a different origin. By default, browsers enforce the Same-Origin Policy, which blocks cross-origin HTTP requests made by JavaScript. CORS provides a way for servers to explicitly allow specific cross-origin requests while blocking others.

Without proper CORS configuration, your front-end application hosted on app.example.com cannot fetch data from your API at api.example.com — even though you own both domains.

How Does CORS Work?

CORS works through HTTP headers exchanged between the browser and server:

  1. Simple Requests: For basic GET/POST requests, the browser sends the request with an Origin header. The server responds with Access-Control-Allow-Origin to permit or deny access.
  2. Preflight Requests: For complex requests (PUT, DELETE, custom headers), the browser first sends an OPTIONS request (preflight) to check if the actual request is permitted. The server responds with allowed methods, headers, and origins.
  3. Credentialed Requests: Requests with cookies or auth tokens require Access-Control-Allow-Credentials: true and cannot use wildcard (*) origins.

Key CORS Headers

HeaderPurposeExample
Access-Control-Allow-OriginSpecifies allowed originshttps://app.example.com or *
Access-Control-Allow-MethodsSpecifies allowed HTTP methodsGET, POST, PUT, DELETE
Access-Control-Allow-HeadersSpecifies allowed request headersContent-Type, Authorization
Access-Control-Max-AgeHow long preflight results can be cached (seconds)86400
Access-Control-Allow-CredentialsWhether cookies/auth can be includedtrue

Common Use Cases

  • Single-Page Applications: SPAs hosted on a CDN or separate domain need CORS to call backend APIs.
  • Microservices Architecture: Different services on different domains must communicate via CORS-enabled APIs.
  • Third-Party API Integration: Consuming public APIs from browser-based applications requires proper CORS headers.
  • Development Environments: Local dev servers (e.g., localhost:3000) need CORS to talk to staging APIs.

How to Use This Tool

  1. Select the allowed HTTP methods (GET, POST, PUT, etc.).
  2. Enter the allowed origins (domains) for cross-origin requests.
  3. Configure additional options like allowed headers and credentials.
  4. Copy the generated CORS headers or middleware code for your server.

Why Use This Tool?

  • Quickly generate correct CORS configuration for your API.
  • Avoid common CORS misconfiguration errors.
  • Supports multiple server frameworks and languages.
  • Essential for any API consumed by browser-based applications.

Frequently Asked Questions

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

Only for public APIs that do not require authentication. Wildcard origins cannot be combined with credentials (Access-Control-Allow-Credentials: true). For authenticated APIs, always specify exact origins.

Why do I get CORS errors in development but not in production?

This usually happens because your development server runs on a different port (e.g., localhost:3000) than your API (e.g., localhost:5000). Different ports count as different origins. Configure your API to allow your dev server's origin during development.