CORS Header Generator

Create and configure CORS headers for cross-origin requests.

Use '*' to allow all origins (cannot be used with credentials)
0 (no cache)86400 (24 hours)

Generated CORS Headers

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 3600

When to use this generator

  • A browser calls your API from another origin (different scheme, host, or port) and the console shows a CORS or preflight failure.
  • You are writing infra-as-code, nginx, API Gateway, or Lambda config and need the exact header lines to paste.
  • You want to compare a strict setup (named origins, no credentials) vs a dev-only relaxed setup before you lock production.

Real-world example

A React app at https://app.example.com posts JSON with Authorization to https://api.example.com. You allow that origin (not *), include OPTIONS, list Content-Type and Authorization in allow-headers, and set Allow-Credentials: true because you use cookies—this tool outputs the matching header block for you to wire into the server.

Common mistakes

  • * with credentials: browsers reject it; list explicit origins.
  • Missing custom headers (e.g. X-Request-Id) in allow-headers—preflight fails even when GET works.
  • Forgetting OPTIONS on the server route so preflight never returns 204/200 with these headers.

Limitations of this tool

  • It only builds static header text—your framework may need middleware syntax (Express cors(), Spring config, etc.).
  • It does not model dynamic origin allowlists, regex origins, or per-route policies—you must merge that logic yourself.
  • CORS is not a substitute for authn/authz; permissive headers do not make an API safe.
By Muhammad Abdullah Rauf · Founder, EverydayTools.proUpdated 2026

Workflow guides

Step-by-step chains that connect related tools for common tasks.

Configure CORS for a REST API endpoint

  1. Enter your allowed origin (e.g. https://app.example.com), methods (GET, POST, PUT), and custom headers (Authorization, Content-Type).
  2. Copy the generated header block into your server config (NGINX location block, Express middleware, or API Gateway response header mapping).
  3. Convert any curl test command to a fetch() call with cURL to Fetch Converter to verify the request includes the correct headers.

Advertisement

Frequently Asked Questions

What does Access-Control-Allow-Origin do?

Access-Control-Allow-Origin tells the browser which origins are permitted to read the response. Setting it to * allows any origin; setting it to https://example.com restricts access to that specific domain. Without this header, browsers block cross-origin fetch and XHR responses under the Same-Origin Policy.

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

When your request includes cookies or HTTP authentication, set Access-Control-Allow-Credentials: true on the server. The browser will only expose the response to JavaScript if this header is present. Note: you cannot combine credentials:true with Access-Control-Allow-Origin: * — you must specify the exact origin.

What is a CORS preflight request?

Browsers send an OPTIONS preflight before 'non-simple' cross-origin requests (custom headers, non-GET/POST methods, or JSON content-type). The server must respond with the appropriate Access-Control headers. This tool generates the full preflight response header block so you can configure your server or API gateway correctly.

Which HTTP methods require CORS configuration?

All cross-origin requests need CORS headers, but simple requests (GET, POST with basic content types) bypass preflight. Methods like PUT, PATCH, DELETE, or any request with custom headers (Authorization, Content-Type: application/json) always trigger a preflight. Include all used methods in Access-Control-Allow-Methods.

More free tools for the same workflow.

Advertisement