CORS Header Builder
Compose a coherent set of CORS response headers for one explicit origin.
Compose CORS headers without invalid combinations
Cross-Origin Resource Sharing is enforced by browsers through a coordinated set of response headers. This builder validates one exact origin or a wildcard, an explicit method list, HTTP-token request-header names, credential behavior, and a non-negative preflight cache duration. It also adds Vary: Origin for a specific origin so shared caches do not reuse one origin response for another.
The defaults allow https://app.example.com to send GET and POST requests with Content-Type and Authorization headers, enable credentials, and cache the preflight result for 600 seconds. A credentialed configuration using a wildcard is rejected because browsers forbid that pairing. Paths are also rejected in the origin field because an origin consists only of scheme, host, and port.
Static origins and dynamic allowlists
A static header can represent only one specific allowed origin. Servers with an allowlist must compare the request Origin and echo an approved value dynamically rather than emit multiple origins in one header. The builder runs in your browser and sends no preflight request. Confirm route-specific methods, credential policy, exposed response headers, and cache behavior in the actual server framework.
Frequently Asked Questions
Why can credentials not be combined with a wildcard origin?
The CORS protocol requires an explicit origin when cookies or HTTP authentication credentials are allowed.
Why is Vary: Origin included?
It tells shared caches that responses can differ by request Origin, preventing reuse across different sites.
Can Access-Control-Allow-Origin contain a list?
No. A response carries one allowed origin or a wildcard; dynamic servers must select one approved request origin.
Browse the full set of free, private, in-browser tools.