Paste the raw HTTP response headers (from DevTools → Network tab → Response Headers)
Quick examples:
Ready to validate
Paste response headers and click Validate// check if cors headers are correctly configured
Validate CORS headers from HTTP responses. Check Access-Control-Allow-Origin, methods, credentials, and preflight config instantly — free and browser-based.
Paste the raw HTTP response headers (from DevTools → Network tab → Response Headers)
Ready to validate
Paste response headers and click ValidateOpen DevTools → Network → click a request → scroll to Response Headers section and copy all CORS-related headers.
Paste the headers into the input. Optionally enter your frontend origin and the HTTP method you're using.
Each CORS header is checked individually. Errors and warnings include actionable fix instructions.
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts web pages from making requests to a different domain than the one that served the page. Servers signal allowed origins via HTTP response headers. Misconfigured CORS is one of the most common sources of API integration failures.
The most common causes are: (1) Access-Control-Allow-Origin value doesn't exactly match your requesting origin, (2) the header is set on the wrong response (e.g., only on 200 but not OPTIONS preflight), or (3) Access-Control-Allow-Credentials: true is combined with a wildcard origin (*), which browsers reject.
A preflight is an automatic OPTIONS request sent by browsers before "non-simple" cross-origin requests. It's triggered when using methods other than GET/POST/HEAD, custom headers like Authorization, or Content-Type other than standard form types. The server must respond with appropriate Access-Control-Allow-* headers to approve the actual request.
No. Wildcard origin (*) is incompatible with Access-Control-Allow-Credentials: true. If you need to send cookies or HTTP authentication cross-origin, you must specify an exact origin (e.g., https://app.example.com) and set credentials to true on both the server response and your fetch() call.
It tells browsers how long (in seconds) to cache the preflight response. Without it, browsers send an OPTIONS request before every cross-origin request. Setting it reduces network overhead significantly. Chrome caps at 7200s, Firefox at 86400s regardless of what you set.
If your server dynamically echoes the requesting origin in Access-Control-Allow-Origin (instead of using *), CDNs and reverse proxies might cache that response and serve it to requests from different origins — causing them to fail. Adding Vary: Origin tells caches to store separate responses per origin value.
Simple requests (no preflight) use only GET, POST, or HEAD, standard Content-Type values (text/plain, multipart/form-data, application/x-www-form-urlencoded), and no custom headers. Everything else — custom headers, JSON Content-Type, DELETE/PUT/PATCH methods — triggers a preflight OPTIONS check first.
For truly public, read-only APIs (like public data endpoints), wildcard is fine. For anything involving authentication, private data, or write operations, always use a specific origin whitelist. A wildcard on a sensitive endpoint means any website can make requests to it using a logged-in user's browser session.
CORS is a browser-enforced policy — it doesn't protect your server from direct requests made by curl, Postman, or server-to-server calls. It only restricts browser-based cross-origin JavaScript. For real security, always validate authentication and authorization on the server side, regardless of CORS configuration.
Cross-Origin Resource Sharing (CORS) errors are among the most frustrating issues a web developer can face. The browser gives you a terse error in the console, your API call silently fails, and deciphering which specific header is wrong requires knowledge of browser security internals. This CORS Header Validator tool cuts through that confusion by analyzing your HTTP response headers line by line, flagging misconfigurations, missing values, and dangerous combinations before they reach production.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and developer tools — worth checking out.
CORS is implemented entirely through HTTP headers. The server communicates its policy to browsers via a specific set of response headers, and browsers enforce that policy by blocking responses that don't match. Here's what each header does:
Access-Control-Allow-Origin — Specifies which origin(s) are permitted. Can be a specific origin (https://app.com) or wildcard (*). This is the most critical header.Access-Control-Allow-Methods — Lists permitted HTTP methods (GET, POST, DELETE, etc.) for cross-origin requests.Access-Control-Allow-Headers — Declares which request headers the client is allowed to send (e.g., Authorization, Content-Type).Access-Control-Allow-Credentials — When true, allows cookies and HTTP authentication to be included in cross-origin requests.Access-Control-Max-Age — How long browsers should cache the preflight result in seconds, reducing repeated OPTIONS requests.Access-Control-Expose-Headers — Whitelists response headers that JavaScript in the browser is allowed to read.Vary: Origin — Instructs CDNs and proxies to cache responses per-origin, preventing incorrect caching of CORS policies.After analyzing thousands of API configurations, certain mistakes appear repeatedly. Knowing them helps you diagnose and fix CORS issues faster:
Setting Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true simultaneously is invalid. The browser specification explicitly forbids this combination. If you need credentialed requests, you must echo the specific requesting origin in the Allow-Origin header and dynamically handle multiple allowed origins server-side.
A very common mistake is configuring CORS correctly for regular responses but forgetting to handle OPTIONS preflight requests. Browsers send OPTIONS before non-simple requests, and if your server returns a 404 or 405 for OPTIONS without CORS headers, the actual request never fires. Ensure your server explicitly handles OPTIONS for CORS-enabled routes.
Origin matching is exact, including protocol, hostname, and port. https://app.com and https://app.com:443 are treated differently in some contexts. Similarly, a trailing slash difference (https://app.com vs https://app.com/) can cause mismatches. Always test with the exact origin string your frontend uses.
If your server dynamically sets Access-Control-Allow-Origin based on the incoming Origin header, omitting Vary: Origin can lead to CDNs serving a cached response with the wrong origin to different clients. This causes intermittent CORS failures that are extremely hard to debug, as they only appear when cached responses are served.
To use this validator, you need the raw response headers from a real request. Here's how to find them in major browsers:
Copy all the Access-Control-* lines (and Vary if present) and paste them into this validator. You can include the full response headers — the tool will parse and extract the relevant CORS fields automatically.
Different backend stacks configure CORS differently. Here are the correct ways for common environments:
Use the cors npm package with an options object specifying origin, methods, allowedHeaders, and credentials. Avoid cors() with no arguments in production as it permits all origins.
Add CORS headers using the add_header directive inside your location block. Critically, you must handle OPTIONS requests separately with a if ($request_method = OPTIONS) block that returns a 204 with the appropriate headers.
Use Header set Access-Control-Allow-Origin inside a <Directory> or <Location> block. The mod_headers module must be enabled. For dynamic origin whitelisting, use SetEnvIf with conditional Header directives.
CORS only applies to browsers. You won't see CORS errors in curl, Postman, or server-to-server calls — only in browser JavaScript. During development, if you're running frontend on localhost:3000 and API on localhost:8080, those are considered different origins and CORS applies. This validator helps you confirm your dev/staging CORS config before pushing to production.
A well-configured CORS policy is one of the fundamentals of a secure, functional web API. This tool helps you get it right the first time — paste your headers, see the diagnosis, and ship with confidence.