CORS Header Builder & Generator
Generate CORS headers interactively. Output as HTTP headers, Nginx config, Express middleware, or Apache .htaccess.
Headers the browser should expose to client-side JavaScript via getResponseHeader().
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400How to Use
- Start by configuring allowed origins. Enable the wildcard option for public APIs, or add specific origin URLs like
https://app.example.comone at a time for more controlled access. - Select the HTTP methods your API accepts. Most REST APIs need GET, POST, PUT, and DELETE at minimum. Include OPTIONS if you want to explicitly list it (browsers send it automatically for preflight).
- Check the request headers your API expects. Content-Type and Authorization are the most common. Add any custom headers your application uses via the custom header input.
- Optionally add expose headers if your API returns custom response headers that JavaScript needs to read (e.g., X-Request-Id, X-RateLimit-Remaining).
- Set the Max Age to control how long browsers cache preflight results, and toggle Allow Credentials if your API uses cookies or auth headers.
- Choose your output format — raw HTTP headers, Nginx config, Express.js middleware, or Apache .htaccess — and click Copy.
What is CORS?
Cross-Origin Resource Sharing (CORS) is a security mechanism implemented by web browsers that controls how web pages from one origin can request resources from a different origin. An origin is defined by the combination of protocol, domain, and port — so https://app.example.com and https://api.example.com are different origins, even though they share the same root domain.
CORS was introduced to relax the Same-Origin Policy (SOP), which by default prevents JavaScript from making requests to a different origin than the page it runs on. While the SOP is essential for security — it prevents a malicious site from reading your bank account data via an AJAX call — it also blocks legitimate cross-origin requests that modern web applications depend on, such as calling an API hosted on a different subdomain or a third-party service.
CORS works through a set of HTTP response headers that tell the browser which origins, methods, and headers are allowed. When a browser detects a cross-origin request, it checks these headers to decide whether to allow the response to be accessed by the JavaScript code that initiated the request.
The Same-Origin Policy
The Same-Origin Policy is one of the most fundamental security mechanisms in web browsers. It restricts how scripts loaded from one origin can interact with resources from another origin. Two URLs have the same origin only if they share the same protocol (http vs https), host (example.com vs api.example.com), and port (80 vs 8080). The SOP applies to XMLHttpRequest, the Fetch API, Web Fonts loaded via @font-face, WebGL textures, and canvas images drawn with drawImage.
Without the SOP, any website you visit could silently make authenticated requests to your email, bank, or social media accounts using your existing cookies. The SOP prevents this by ensuring that JavaScript on one site cannot read responses from another site. CORS provides a controlled mechanism for servers to opt in to cross-origin access when it is intentional and safe.
How Preflight Requests Work
Not all cross-origin requests trigger a preflight. Simple requests — those using GET, HEAD, or POST with standard headers and content types — are sent directly, with the browser checking CORS headers on the response. But when a request uses a non-simple method (PUT, DELETE, PATCH), includes custom headers (like Authorization), or sends a Content-Type other than the three allowed types, the browser first sends an OPTIONS request called a preflight.
The preflight request includes Access-Control-Request-Method and Access-Control-Request-Headers headers that tell the server what the actual request will look like. The server must respond with Access-Control-Allow-Methods and Access-Control-Allow-Headers confirming that these are permitted. Only if the preflight succeeds does the browser send the actual request. The Access-Control-Max-Age header caches this preflight result so subsequent requests skip the OPTIONS check.
Common CORS Errors and Fixes
The most frequent CORS error is "No 'Access-Control-Allow-Origin' header is present on the requested resource." This means your server is not returning the required header. The fix is to add the Access-Control-Allow-Origin header to your server's response, either as a wildcard * or the specific requesting origin.
Another common error is "The value of the 'Access-Control-Allow-Origin' header must not be the wildcard '*' when the request's credentials mode is 'include'." This occurs when your frontend sends credentials: 'include' with fetch but the server returns Access-Control-Allow-Origin: *. The fix is to return the specific origin instead of the wildcard and add Access-Control-Allow-Credentials: true.
Preflight failures produce errors like "Response to preflight request doesn't pass access control check." This usually means your server either does not handle OPTIONS requests at all, or does not return the correct Access-Control-Allow-Methods or Access-Control-Allow-Headers in the OPTIONS response. Ensure your server responds to OPTIONS with a 200 or 204 status and the appropriate CORS headers.
Missing exposed headers cause silent failures where response.headers.get('X-Custom-Header') returns null even though the header is present in the network response. Add the header name to Access-Control-Expose-Headers to make it accessible to JavaScript.
CORS with Credentials
When your API uses cookies, HTTP authentication, or TLS client certificates, the browser requires explicit opt-in from both the client and server. On the client side, set credentials: 'include' in fetch options or withCredentials: true in XMLHttpRequest. On the server side, return Access-Control-Allow-Credentials: true and set Access-Control-Allow-Origin to the exact requesting origin — not a wildcard.
This restriction exists for security: if wildcard origins were allowed with credentials, any website could make authenticated requests to your API and read the responses. By requiring an explicit origin, CORS ensures that only the domains you specifically authorize can access authenticated endpoints.
Related Tools
Generate Content Security Policy headers with the CSP Generator. Look up HTTP status codes in the HTTP Status Code Reference. Convert cURL commands to code with the cURL Converter. Decode JSON Web Tokens with the JWT Decoder.
Frequently Asked Questions
- What is CORS and why do I need it?
- CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls which domains can make HTTP requests to your server. Without proper CORS headers, browsers block cross-origin requests made by JavaScript code. You need CORS headers whenever your frontend application (e.g., running on localhost:3000) makes API calls to a server on a different origin (e.g., api.example.com).
- What is a preflight request?
- A preflight request is an automatic OPTIONS request that the browser sends before certain cross-origin requests. It occurs when the request uses methods other than GET, HEAD, or POST, or includes custom headers, or uses a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain. The server must respond to the OPTIONS request with the appropriate Access-Control-Allow-* headers for the actual request to proceed.
- Why can't I use credentials with a wildcard (*) origin?
- Browsers explicitly reject responses that set Access-Control-Allow-Origin to * when the request includes credentials (cookies, authorization headers, or TLS client certificates). This is a security measure to prevent any website from reading authenticated responses from your API. When credentials are needed, you must specify the exact origin(s) that are allowed.
- What does Access-Control-Max-Age do?
- Access-Control-Max-Age tells the browser how long (in seconds) to cache the results of a preflight request. During this time, the browser will not send another OPTIONS request for the same resource and method combination. A value of 86400 (24 hours) is common. This reduces network overhead by eliminating repeated preflight requests for frequently accessed endpoints.
- What is the difference between Allow-Headers and Expose-Headers?
- Access-Control-Allow-Headers specifies which HTTP headers the client is allowed to send in the actual request (e.g., Authorization, Content-Type). Access-Control-Expose-Headers specifies which response headers the browser should expose to client-side JavaScript. By default, only a few simple response headers are accessible; any custom response headers must be listed in Expose-Headers for JavaScript to read them.
- How do I fix "No Access-Control-Allow-Origin header is present" errors?
- This error means your server is not returning the Access-Control-Allow-Origin header in its response. Add the header to your server configuration with either a wildcard (*) or the specific requesting origin. Make sure the header is present on both the preflight OPTIONS response and the actual response. Common causes include missing CORS middleware, incorrect server configuration, or a reverse proxy stripping the headers.
- Should I use a wildcard origin in production?
- Using a wildcard (*) in production is acceptable for truly public APIs that serve public data without authentication. However, for APIs that handle user data, require authentication, or use cookies, you should specify exact allowed origins. Wildcards also prevent the use of credentials and can expose your API to abuse from any website. A common pattern is to maintain a whitelist of allowed origins and dynamically set the header based on the requesting origin.
Use this tool from AI agents.
The CodeTidy MCP Server lets Claude, Cursor, and other AI agents
use this tool and 46 others directly. One command: npx @codetidy/mcp