CORS Header Tester

Cross-Origin Resource Sharing (CORS) is one of the most critical — and most commonly misunderstood — security mechanisms on the web. It governs whether a browser allows a web page running on one origin to request resources from a different origin. When CORS is misconfigured, APIs silently break, frontend apps stop loading data, and developers spend hours debugging opaque "blocked by CORS policy" errors. Our free CORS Header Tester removes the guesswork by fetching any URL from our server and displaying every CORS response header — including Access-Control-Allow-Origin, allowed methods, whether credentials are permitted, maximum preflight cache duration, and the full set of exposed headers. Whether you're building a public API, debugging a React or Svelte app that can't fetch data, or auditing your server's security posture, this tool gives you instant, readable visibility into exactly how your endpoints handle cross-origin traffic.

What Is CORS?

CORS is a browser-enforced security standard that controls how web pages can request resources from origins different from their own. Without CORS, the web would follow the same-origin policy — a strict rule that blocks any cross-origin HTTP request made from JavaScript. This policy protects users from malicious sites that could otherwise make authenticated requests to your bank, email provider, or social media accounts without your knowledge.

CORS works through a set of HTTP response headers that servers can include to selectively relax the same-origin policy. When a browser makes a cross-origin request, it checks the server's response for specific Access-Control-* headers. If those headers permit the requesting origin, the browser allows the JavaScript to read the response. If they are missing or don't match, the browser blocks the response entirely — the request still reaches the server and executes, but the calling JavaScript code never sees the result. This is why CORS errors are so frustrating: the server successfully processes the request, but the browser refuses to hand the response to your code.

How to Use the CORS Header Tester

1. Enter a URL — Type the full URL of your API endpoint, CDN resource, or any web address you want to inspect (e.g., https://api.github.com/users/octocat). Both HTTP and HTTPS URLs are supported.
2. Click "Test" — Press the Test button or hit Enter. Our server fetches the URL, reads all response headers, and returns them for inspection.
3. Review the CORS status — The summary banner instantly tells you whether CORS headers are present and includes the HTTP status code returned by the server.
4. Analyze CORS headers — Examine each Access-Control-* header individually: which origins are allowed, which HTTP methods are permitted, whether credentials (cookies, authorization headers) are supported, how long preflight responses can be cached, and which response headers are exposed to the calling script.
5. Explore all headers — The complete response headers list is displayed in alphabetical order, with CORS-related headers highlighted for quick scanning. Use this to cross-check related headers like Content-Type, Cache-Control, and security headers.

Key Features

• Complete CORS Inspection

  Checks all six Access-Control-* response headers: Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials, Max-Age, and Expose-Headers.

• Server-Side Fetching

  Requests are proxied through our server so you can inspect headers from any URL without hitting browser CORS restrictions yourself.

• Full Header Listing

  View every response header returned by the target server — not just CORS headers — sorted alphabetically with CORS headers highlighted.

• HTTP Status Display

  See the exact HTTP status code (200, 301, 404, 500, etc.) with color-coded badges for 2xx/3xx/4xx/5xx responses.

• Wildcard Detection

  Instantly identifies when Allow-Origin is set to * (public API) versus a specific origin (restricted access).

• HTTPS & HTTP Support

  Test URLs over both secure (HTTPS) and plain (HTTP) connections. If no protocol is given, HTTPS is assumed automatically.

Understanding CORS Headers

Each CORS response header serves a distinct purpose in the cross-origin request lifecycle. Understanding what each header controls is essential for proper API configuration and debugging:

• Access-Control-Allow-Origin: The most important CORS header. Specifies which origins are permitted to access the resource. Set to * for public APIs, or a specific origin like https://myapp.com for restricted access. Only one origin can be specified; if you need to support multiple specific origins, the server must dynamically echo back the request's Origin header.
• Access-Control-Allow-Methods: Lists the HTTP methods that are allowed when accessing the resource cross-origin. Common values include GET, POST, PUT, DELETE, PATCH, OPTIONS. This header matters for non-simple requests that use methods other than GET, HEAD, or POST.
• Access-Control-Allow-Headers: Specifies which HTTP headers can be used during the actual request. Required when the client sends custom headers like Authorization, Content-Type (with non-standard values), or X-Requested-With.
• Access-Control-Allow-Credentials: When set to true, the browser includes credentials (cookies, TLS client certificates, or authorization headers) with the cross-origin request. Cannot be used when Allow-Origin is *.
• Access-Control-Max-Age: Determines how long (in seconds) the browser can cache the results of a preflight OPTIONS request. Reducing the number of preflight requests improves API performance.
• Access-Control-Expose-Headers: By default, browsers only expose a small set of response headers (Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma) to JavaScript. This header whitelists additional headers that the client-side code may need to read, such as X-RateLimit-Remaining, ETag, or custom pagination headers.

When to Test CORS Headers

• Building a Public API: Before releasing your API, verify that CORS headers are correctly configured to accept requests from your expected clients. A missing Access-Control-Allow-Origin header is the number one reason APIs fail integration tests.
• Debugging Frontend Errors: When your React, Vue, Svelte, or Angular app shows "blocked by CORS policy" in the console, use this tool to instantly check whether the problem is a missing header or an origin mismatch.
• Auditing Third-Party APIs: Before integrating an external API, verify what CORS headers it returns. If the API doesn't support cross-origin requests, you'll need a server-side proxy.
• Security Audits: Ensure your endpoints don't expose overly permissive CORS policies. A wildcard Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true is a security anti-pattern that modern browsers will reject.
• Performance Optimization: Check the Access-Control-Max-Age header to see if preflight responses are properly cached. A max-age of 600+ seconds can significantly reduce OPTIONS requests for repeat API calls.

Frequently Asked Questions