CORS Header Checker

Paste HTTP response headers to analyze your CORS configuration and detect issues instantly.

HTTP Response Headers

How to Use

Get HTTP response headers from your API using curl -I https://your-api.com/endpoint, or copy them from browser DevTools → Network tab → select a request → Response Headers.
Paste the full header block into the text area above. The status line (e.g. HTTP/1.1 200 OK) is optional.
Click Analyze CORS to check your configuration.
Review the color-coded results: green is correct, yellow is a warning, red is a critical error that will block cross-origin requests.
Fix any errors or warnings in your server or API gateway configuration, then re-test.

About This Tool

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that restricts how web pages can request resources from a different domain. Misconfigured CORS headers are one of the most common causes of API integration failures — everything works in Postman or curl but breaks in the browser. This tool parses your raw HTTP response headers, extracts all Access-Control-* headers, and validates them against the CORS specification. It catches critical issues like the forbidden combination of a wildcard origin with credentials, missing headers that break preflight requests, invalid header values, and performance issues from uncached preflights. All analysis runs entirely in your browser — no headers are ever sent to any server.

Frequently Asked Questions

Why does CORS only block browser requests but not curl or Postman?

CORS is enforced by browsers as a security feature, not by servers. Command-line tools like curl and API clients like Postman have no concept of an "origin", so they send and receive requests without any restrictions. The CORS headers on the server response tell the browser whether JavaScript on a given page is allowed to read the response. The browser then either grants or denies access based on those headers.

When is `Access-Control-Allow-Origin: *` unsafe?

The wildcard * allows any origin to read the response. This is acceptable for fully public APIs (like a weather API or open dataset). However, if you also send Access-Control-Allow-Credentials: true, the combination is forbidden by the CORS specification and browsers will block the response entirely. For authenticated endpoints, you must specify the exact allowed origin (e.g. https://app.example.com) rather than using a wildcard.

What is a preflight request and when is it sent?

For requests that are not "simple" — such as PUT, DELETE, PATCH, or any request with an Authorization header or Content-Type: application/json — browsers automatically send an OPTIONS preflight request first. This preflight asks the server: "Can this origin make this type of request?" Your server must respond to OPTIONS with the appropriate Access-Control-Allow-Methods and Access-Control-Allow-Headers headers, or the actual request will never be sent.

What does `Access-Control-Max-Age` do?

This header tells the browser how long (in seconds) to cache the preflight response. Without it, the browser sends a preflight OPTIONS request before every non-simple API call, adding latency. Setting it to 86400 (24 hours) means the browser caches the preflight result for a day, eliminating the extra round-trip for subsequent requests.