DevCoreTools

CORS Header Explainer / Generator

Generate CORS headers, understand browser behavior, and avoid common cross-origin configuration mistakes.

CORS builder

Choose origins, methods, headers, and credential behavior for example server responses.

Processed locally in your browser Limit header text. Your input is processed in your browser and is not uploaded or sent to a server. Avoid pasting production secrets, access tokens, private keys, passwords, or sensitive customer data unless you understand the risk.
Allowed origin
Allowed methods
Allowed request headers
Exposed response headers

Generated response headers

Copy these examples into server, gateway, or framework configuration and adapt them to real request handling.

Ready to adapt5 headershttps://app.example.com

HTTP response headers

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type, Accept
Access-Control-Expose-Headers: ETag, RateLimit-Remaining
Access-Control-Max-Age: 600

Header explanations

HeaderValueBrowser meaning
Access-Control-Allow-Originhttps://app.example.comAllows this specific origin to read the response when the browser request matches it.
Access-Control-Allow-MethodsGET, POST, PUT, PATCH, DELETE, OPTIONSLists response methods the browser may use after a successful preflight request.
Access-Control-Allow-HeadersAuthorization, Content-Type, AcceptLists non-simple request headers the browser may send after preflight approval.
Access-Control-Expose-HeadersETag, RateLimit-RemainingAllows browser JavaScript to read these response headers.
Access-Control-Max-Age600Tells browsers how long, in seconds, they may cache a successful preflight response.

Preflight flow

  1. Browser detects a cross-origin request

    If the request is not simple, the browser sends an OPTIONS preflight before the real request.

  2. Browser asks for method and headers

    The preflight includes Origin, Access-Control-Request-Method, and optionally Access-Control-Request-Headers such as Authorization, Content-Type, Accept.

  3. Server returns matching CORS headers

    The response should include this origin plus allowed methods such as GET, POST, PUT, PATCH, DELETE, OPTIONS.

  4. Browser sends the real request

    When the preflight matches, the browser proceeds. Otherwise browser JavaScript receives a CORS failure.

Examples only.

Browsers enforce CORS. Your server, CDN, or gateway must return matching headers for the actual Origin, method, request headers, credentials mode, and OPTIONS preflight behavior.

CORS and same-origin policy basics

CORS is a browser protocol. It lets servers opt in to selected cross-origin reads while the same-origin policy remains the default boundary.

Same-origin policy

Browsers compare scheme, host, and port. JavaScript can freely read same-origin responses, but cross-origin reads need matching CORS response headers.

Simple requests

Some GET, HEAD, and POST requests with simple headers may skip preflight, but the final response still needs a matching Access-Control-Allow-Origin.

Preflight requests

For methods or headers outside the simple request rules, browsers send OPTIONS first and check allowed method and header responses before continuing.

Credentialed requests

Cookies, HTTP auth, and client certificates require browser code to request credentials and the server to use an explicit origin plus Access-Control-Allow-Credentials: true.

Common errors

CORS failures often mean the server skipped OPTIONS, returned the wrong origin, omitted requested headers, or used * with credentials.

Server responsibility

This tool generates examples only. Real implementations must compare the request Origin, decide whether to allow it, and return one matching response.

Keep working

View all Security tools
HTTP Headers Parser / FormatterAPI & Auth ToolsParse, format, inspect, and export HTTP headers locally with structured warnings.CSP Header GeneratorGenerate Content Security Policy headers with directives, warnings, and copy-ready output.HTTP Status Code LookupAPI & Auth ToolsLook up HTTP response status codes locally with meanings, examples, and API notes.URL Parser / Query String ParserEncoding & DecodingParse full URLs, relative URLs, and query strings into structured parts.User Agent ParserAPI & Auth ToolsDecode browser, OS, device, engine, and bot hints from user agent strings locally.OpenAPI ValidatorAPI & Auth ToolsValidate OpenAPI and Swagger specs locally with structured errors and warnings.

FAQ

Does this tool test a live website or API?

No. It does not perform network requests, fetch URLs, or validate live servers. It only explains behavior and generates local header examples.

Can I send multiple origins in Access-Control-Allow-Origin?

No. The response header has one origin value or *. For multiple allowed sites, server code usually checks the request Origin against an allowlist and echoes one match.

Why does wildcard origin fail with credentials?

Browsers reject Access-Control-Allow-Origin: * together with credentialed CORS. Use a specific origin when cookies, Authorization, or other credentials are involved.

Do CORS headers secure my API from non-browser clients?

No. CORS is enforced by browsers. APIs still need authentication, authorization, CSRF protection where applicable, input validation, and normal server-side controls.

Why is OPTIONS handling important?

Many cross-origin browser requests are preflighted. If the server does not answer OPTIONS with matching CORS headers, the browser blocks the real request.