CORS Headers Builder

What is the CORS Headers Builder?

Cross-Origin Resource Sharing (CORS) is the mechanism browsers use to decide whether a web page running on one origin (https://app.example.com) is allowed to make requests to a server on another origin (https://api.example.com). By default, browsers block those requests — the server has to opt in by sending back a specific set of Access-Control-* response headers. This tool builds those headers from a few structured fields, so you don't have to memorize the exact header names, comma-joining rules, or the true/* quirks that trip people up.

How to use it

1. Set the Allowed Origin — either a specific origin like https://example.com, or * to allow any site (only valid when credentials are off).
2. List the Allowed Methods and Allowed Headers your API accepts, comma-separated.
3. Toggle Allow Credentials on if the request needs to carry cookies or an Authorization header — this forces you to use a specific origin instead of *.
4. Set Max-Age to control how long browsers cache a preflight OPTIONS response before re-checking, and optionally list Expose Headers for any custom response headers your client-side JavaScript needs to read.
5. The Generated CORS Headers box updates automatically — copy it into your server's response, or download it as a text file.

The role of each header

• Access-Control-Allow-Origin — which origin(s) may read the response. This is the header that actually unlocks cross-origin access; without it, the browser blocks the response regardless of what else is set.
• Access-Control-Allow-Methods — the HTTP methods the server accepts from cross-origin requests, sent in response to a preflight OPTIONS request.
• Access-Control-Allow-Headers — the request headers a cross-origin client is allowed to set (e.g. Content-Type, Authorization).
• Access-Control-Allow-Credentials — must be the literal string true for the browser to expose cookies and HTTP auth to the requesting page. Its presence also requires a specific Allow-Origin, never *.
• Access-Control-Max-Age — how many seconds the browser may cache a preflight result before sending another OPTIONS request. Higher values mean fewer preflights but slower rollout of permission changes.
• Access-Control-Expose-Headers — by default, JavaScript can only read a small set of "safe" response headers. List any custom ones here (e.g. X-Request-Id) to make them readable via fetch/XMLHttpRequest.

FAQ

Why can't I use * with credentials? It's a deliberate browser security restriction. If Access-Control-Allow-Credentials: true were allowed alongside a wildcard origin, any website in the world could make authenticated requests to your API using a logged-in user's cookies. Browsers refuse to honor that combination — this tool flags it before you ship it.

What triggers a preflight (OPTIONS) request? Simple requests — GET, HEAD, or POST with standard content types — go straight to the server. Anything else (a PUT/DELETE/PATCH method, a custom header like Authorization, or a JSON Content-Type) makes the browser send an automatic OPTIONS preflight first, checking the Access-Control-Allow-* headers before it sends the real request.

Do I need Access-Control-Expose-Headers? Only if your frontend JavaScript reads response headers beyond the default safelist (Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma). Pagination headers, request IDs, and rate-limit counters are common cases that need it.

Can I allow multiple specific origins? CORS only allows one static value in Access-Control-Allow-Origin per response. To support multiple known origins, your server needs to check the incoming Origin request header against an allow-list and echo back the matching one dynamically — this tool builds the header block for a single origin at a time.

Privacy

This tool runs entirely in your browser. The origins, methods, and headers you enter are never sent to or stored on our servers.