Why do I get CORS errors?

Either the server isn't sending the headers the browser needs, or the preflight request is failing for some related reason. The usual culprits are a missing Access-Control-Allow-Origin, a preflight response that didn't list the methods or headers your fetch is using, a typo in the origin string, or a credentials misconfiguration. Generating the headers from a known-good template is the fastest way out of that loop.

What's a preflight request?

When the browser is about to send a request that isn't 'simple' — anything using PUT or DELETE, custom headers like Authorization, or non-trivial content types — it first sends an OPTIONS request to ask the server whether the actual request will be accepted. The server has to respond with the right Allow-Methods and Allow-Headers values, and if that preflight fails, the real request is never sent.

What does 'Access-Control-Allow-Origin: *' mean?

It's the wildcard that lets any origin access the resource, and it's the easiest setting to apply. The wildcard is fine for unauthenticated, public APIs but cannot coexist with Access-Control-Allow-Credentials being true — browsers explicitly reject that combination. Anytime cookies or Authorization headers are involved, you have to echo back a specific origin string instead.

How do I allow multiple specific origins?

The Access-Control-Allow-Origin header only takes one value. For multiple origins, the server has to read the incoming Origin header, check it against an allowlist, and echo it back if it matches. Don't reflect whatever the request sent without verifying — that effectively turns every site into an allowed origin. The standard pattern is something like 'const allowed = [origin1, origin2]; if (allowed.includes(origin)) respond.setHeader(...)'.

What headers control CORS?

Access-Control-Allow-Origin governs which origins are accepted. Allow-Methods lists permitted HTTP methods. Allow-Headers names the custom request headers your client is allowed to send. Allow-Credentials toggles whether cookies and Authorization can ride along. Max-Age sets how long the browser caches a preflight response. And Expose-Headers names response headers that JavaScript on the calling page is allowed to read.

Can server-side code bypass CORS?

CORS only exists inside the browser. Server-side code written in Node, Python, Go, or anything else makes HTTP calls without any CORS check at all — that's why a curl request walks right past restrictions a browser would enforce. The legitimate way to work around CORS for your own frontend is to proxy the request through your own backend, which then has free access to whatever third-party API you need.

Is CORS sufficient security?

Not on its own. CORS prevents incidental cross-origin data leaks via the browser, but it does nothing against any caller that isn't a browser, and a determined attacker has plenty of ways to skip the browser entirely. Real protection still requires authentication, authorization checks, input validation, and rate limiting on the server side. Treat CORS as one layer in defense-in-depth, never the whole strategy.

CORS Header Generator

Generate CORS (Cross-Origin Resource Sharing) headers with a visual builder. Explanation of each option included. Free CORS config tool.

Web & SEO Developer Tools

Instant results

Configuration

Access-Control-Allow-Origin

* (Any origin)Specific origins

Access-Control-Allow-Methods

Access-Control-Allow-Headers

Access-Control-Expose-Headers

Max-Age

24h 0m

Credentials

Allow

Output

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

Header Explanations

Allow-Origin — Specifies which origins can access the resource. Use '*' for any origin, or list specific domains for security.

Allow-Methods — Specifies which HTTP methods are allowed when accessing the resource during preflight requests.

Allow-Headers — Specifies which HTTP headers can be used during the actual request. Browsers send these in preflight.

Expose-Headers — Specifies which response headers the browser should expose to the requesting client code.

Max-Age — How long (in seconds) the results of a preflight request can be cached. Reduces preflight requests.

Credentials — Whether the browser should include credentials (cookies, HTTP auth, TLS client certs) with requests. Cannot be used with origin: '*'.

How to Use CORS Header Generator

Specify allowed origins

Decide who can call your API. The wildcard '*' is fine for genuinely public read-only endpoints, while a specific origin like https://app.example.com is what you want for any production use. If you need several origins, the right approach is server-side logic that checks the incoming Origin against an allowlist and echoes it back when it matches.

Choose allowed methods

Pick the HTTP methods your API actually uses — GET, POST, PUT, DELETE, OPTIONS, PATCH. Stick to least privilege here. There's no upside to enabling DELETE on an endpoint that only ever reads, and the tighter list reduces the attack surface if anything else slips through your auth layer.

Configure headers and credentials

List the custom headers your client actually sends — Authorization, Content-Type with a non-simple value, X-CSRF-Token, anything else — so the preflight succeeds. Toggle credentials on if cookies or Authorization need to ride along, and remember that enabling credentials forces you to use a specific origin rather than the wildcard, since browsers explicitly reject that combination.

Copy the CORS headers

Paste the generated headers into your server config — the nginx, Apache, Express, or framework-specific snippet that matches your stack — or send them on the API response directly. With everything wired up, your frontend should hit the API without the browser console barking 'blocked by CORS policy', and the OPTIONS preflight (visible as a separate row in devtools) should return cleanly.

When to Use CORS Header Generator

Letting an API serve a frontend on another domain

Anytime your frontend lives on api.example.com or app.example.com while your API runs somewhere else, you need the right Access-Control-Allow-Origin (and friends) on the response. This is the daily reality for SaaS APIs, public APIs, microservice architectures, and any project where the frontend and backend are deployed independently.

Debugging CORS errors

Once the browser console starts barking 'blocked by CORS policy', the question is always which header is missing or wrong. The usual suspects are an absent Allow-Origin, a preflight that didn't include the needed methods, or an Allow-Headers list that forgot the custom header your fetch is sending.

Strict CORS policies for production

Production traffic should not be running on a wildcard origin. You want an explicit allow-list, proper credentials handling, and a sensible preflight cache. This is especially true for enterprise APIs and multi-tenant SaaS where each customer subdomain needs to be validated rather than blindly accepted.

Learning CORS

CORS has a reputation for being confusing, and most of that comes from people not really understanding the difference between simple and preflighted requests, or what each header is actually doing. Generating a working configuration alongside the explanation is a much faster path than reading the spec cold, and it helps anyone reviewing API security work.

CORS Header Generator Examples

Public API (any origin)

Input

Allow any origin, GET only

Output

Access-Control-Allow-Origin: *\nAccess-Control-Allow-Methods: GET

This is the simplest possible CORS setup, suitable for an unauthenticated read-only API where you really don't care which frontend is calling. The wildcard origin lets anyone in, and limiting methods to GET keeps things safe. Just remember the wildcard cannot be combined with credentials, so this only works when you don't need cookies or Authorization headers.

Specific origins with credentials

Input

Allow https://app.example.com, methods: GET POST, with credentials

Output

Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Methods: GET, POST\nAccess-Control-Allow-Credentials: true\nAccess-Control-Allow-Headers: Authorization, Content-Type

This is the production-ready shape. The origin is named explicitly, credentials are turned on so cookies and Authorization headers ride along, and the common headers your fetch needs are listed. It's the standard recipe for any SaaS API where logged-in users hit endpoints from a known frontend domain.

Preflight handling

Input

Preflight cache 1 day, all custom headers allowed

Output

Access-Control-Allow-Headers: *\nAccess-Control-Max-Age: 86400

Setting Max-Age to 86400 tells the browser to cache the OPTIONS response for a full day, which is one of the simplest perceptible-latency wins you can give an API that uses custom headers. Allow-Headers can be a wildcard or, more responsibly, an explicit list of the headers your client actually sends.

Tips & Best Practices for CORS Header Generator

1.Never combine a wildcard origin with credentials enabled. Browsers explicitly reject Access-Control-Allow-Origin set to * alongside Access-Control-Allow-Credentials true, so anytime cookies or Authorization headers are involved you have to echo back a specific origin string.
2.Don't lean on CORS for security. The whole mechanism only exists in browsers, and a curl call or a server-to-server request walks right past it. Real protection still has to come from authentication, authorization, and input validation on the server itself.
3.Cache preflights aggressively. A Max-Age between one day and one week is a sane default that cuts the OPTIONS round trip out of nearly every request after the first, and most APIs don't change their CORS rules often enough for a longer cache to cause problems.
4.The single most common CORS error is a missing entry in Allow-Headers. If your frontend is sending Authorization, Content-Type with a non-simple value, or anything custom like X-CSRF-Token, that header has to appear in Access-Control-Allow-Headers or the preflight will fail.
5.Don't echo back the Origin header without checking it first. A naive implementation that reflects whatever Origin shows up effectively turns every site into an allowed origin. Maintain an explicit allow-list and only echo when the request matches.
6.Always debug with the browser devtools network tab open. You'll see the OPTIONS preflight as a separate row from the main request, and CORS issues frequently fail at the preflight step rather than the actual call. Inspecting the headers on both requests in turn is the fastest way to find the misconfiguration.

Frequently Asked Questions

CORS stands for Cross-Origin Resource Sharing, and it's the browser security mechanism that decides whether JavaScript running on one origin (the combination of protocol, domain, and port) is allowed to access another origin's resources. By default the browser refuses, and CORS response headers from the server are how the cross-origin caller gets explicitly let in. It's essentially mandatory for any modern app that splits its frontend and backend onto different domains.

CORS Header Generator

Configuration

Output

Header Explanations

How to Use CORS Header Generator

Specify allowed origins

Choose allowed methods

Configure headers and credentials

Copy the CORS headers

When to Use CORS Header Generator

Letting an API serve a frontend on another domain

Debugging CORS errors

Strict CORS policies for production

Learning CORS

CORS Header Generator Examples

Public API (any origin)

Specific origins with credentials

Preflight handling

Tips & Best Practices for CORS Header Generator

Frequently Asked Questions

Related Tools

Robots.txt Generator

Sitemap Generator

.htaccess Generator

User Agent Parser

URL Parser

HTML Viewer