// quick test:
No CORS test yet
Enter a URL above and click Test CORS to analyze headers// test cors headers from any origin in one click
Test CORS headers for any URL, check allowed origins, methods, and headers, and debug cross-origin resource sharing issues instantly in your browser.
No CORS test yet
Enter a URL above and click Test CORS to analyze headersPaste the API endpoint or resource URL you want to test for CORS support.
Enter the origin domain your browser will send — defaults to https://example.com.
We send a preflight OPTIONS request and display every CORS header in the response.
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls how web pages can request resources from a different domain. When your frontend on app.example.com calls an API on api.other.com, the browser first sends a preflight OPTIONS request to check if the server allows it.
This tool simulates that preflight check server-side, fetching the CORS headers and telling you exactly what the server permits.
A preflight request is an HTTP OPTIONS request sent automatically by the browser before the actual request when certain conditions are met (non-simple methods, custom headers, etc.). The server must respond with the appropriate Access-Control-Allow-* headers for the browser to proceed.
This header tells the browser which origins are allowed to access the resource. If the header is missing or doesn't match your frontend origin, the browser will block the response — even if the server processed the request successfully.
It allows browsers to include cookies and authorization headers in cross-origin requests. When this is set to true, the Access-Control-Allow-Origin header cannot be a wildcard (*) — it must specify the exact origin.
This header tells the browser how long (in seconds) it can cache the preflight response. A higher value reduces the number of preflight requests, improving performance. Common values are 600 (10 minutes) or 86400 (24 hours).
Postman doesn't enforce CORS because it's not a browser. Browsers apply the Same-Origin Policy and require proper CORS headers before allowing cross-origin responses. This tool tests the actual CORS headers your server returns, helping you identify what's missing.
Simple requests (GET/POST with standard content types) don't trigger a preflight. Non-simple requests — PUT, DELETE, or any request with custom headers — trigger a preflight OPTIONS check. This tool always sends a preflight to check your server's CORS policy.
No — this tool makes server-side requests to the URL you provide, so it can only reach publicly accessible URLs. For localhost or private network testing, use your browser's DevTools Network tab to inspect CORS headers directly.
This can happen if the server returns different headers depending on the exact origin or request details, or if there are other browser-level restrictions (like HTTPS/HTTP mismatch). Our tool sends a standard preflight — always verify with your actual app's exact origin and headers.
A CORS Tester is a tool that checks whether a web server properly implements Cross-Origin Resource Sharing (CORS) headers. When you build a web application that fetches data from an external API, your browser enforces strict rules about which servers your frontend is allowed to communicate with. A CORS tester takes the guesswork out of debugging these rules by directly querying the target server and showing you every CORS-related header in plain sight.
Our CORS Tester simulates a preflight OPTIONS request — the exact same kind of request your browser sends before a cross-origin fetch — and displays the complete set of response headers returned by the server. You can specify the exact origin your frontend runs on, choose the HTTP method you plan to use, and immediately see whether the server would permit or block your request.
CORS exists because of the Same-Origin Policy, a foundational browser security rule that prevents scripts on one origin from reading responses from a different origin. Without this policy, malicious scripts on any website could silently read your banking data, steal authentication tokens, or perform actions on your behalf across any website you're logged into.
CORS is the controlled way servers opt into allowing specific cross-origin access. A server can say "only requests from https://myapp.com are allowed" or "all origins are allowed" or "only GET requests are allowed." Without proper CORS headers, the browser will always block the response on the client side — even if the server received and processed the request.
Understanding the six core CORS headers is essential for debugging cross-origin issues:
Access-Control-Allow-Origin is the most fundamental header. It specifies which origins may access the resource. A value of * means any origin is allowed. A specific value like https://app.example.com restricts access to that origin only. If this header is absent, browsers block all cross-origin access to the resource.
Access-Control-Allow-Methods lists the HTTP methods the server permits for cross-origin requests. A typical value might be GET, POST, PUT, DELETE, OPTIONS. If your application needs to make a PUT or DELETE request but the server only allows GET and POST, the preflight will fail and your request will be blocked.
Access-Control-Allow-Headers specifies which HTTP headers the client is allowed to include in the actual request. If your application sends a custom Authorization header or a Content-Type: application/json header, these must be listed in this response header or the preflight will fail.
Access-Control-Allow-Credentials indicates whether the browser should expose the response to the frontend when credentials (cookies, HTTP authentication, TLS certificates) are included. Setting this to true requires the Access-Control-Allow-Origin to be a specific origin, not *.
Access-Control-Max-Age tells browsers how many seconds they can cache the preflight response. This is a performance optimization — instead of sending a preflight before every single cross-origin request, the browser can reuse the cached result. Setting a high value (like 86400) can significantly reduce unnecessary network traffic.
Access-Control-Expose-Headers controls which response headers the browser makes available to JavaScript. By default, only a few "safe" headers are exposed. If your API returns a custom header that your frontend needs to read, it must be listed here.
Not all cross-origin requests trigger a preflight. "Simple" requests — GET or POST with standard content types like application/x-www-form-urlencoded or text/plain — are sent directly. The browser still enforces CORS on the response, but no preflight OPTIONS check is made first.
Preflight requests are triggered by any of the following conditions: the request uses a method other than GET, POST, or HEAD; the request includes custom headers (like Authorization or X-Custom-Header); or the Content-Type header has a value other than the three simple types. The vast majority of modern API requests trigger preflights because they use JSON bodies and authentication tokens.
Our CORS Tester always sends a preflight OPTIONS request regardless, giving you the most complete picture of your server's CORS configuration.
The most common CORS error is "No 'Access-Control-Allow-Origin' header is present on the requested resource." This simply means the server returned no CORS headers at all. The fix is server-side: configure your server, framework, or API gateway to include the appropriate CORS headers.
Another frequent issue is a wildcard origin combined with credentials. If your server sends Access-Control-Allow-Origin: * and your frontend makes a credentialed request (with cookies or Authorization headers), the browser will block it. You must change the origin header to the specific requesting origin.
Method not allowed is another common stumbling block. If you're making a DELETE request but the server only lists GET, POST in Access-Control-Allow-Methods, the preflight fails. Update your server configuration to include the required method.
In Express.js, the cors npm package handles everything: app.use(cors({ origin: 'https://yourapp.com' })). For development, a wildcard origin is often acceptable.
In Django, the django-cors-headers package adds CORS support. Set CORS_ALLOWED_ORIGINS in your settings to a list of trusted frontend origins.
In Laravel, the built-in config/cors.php file controls CORS behavior. Set allowed_origins to your frontend URL and include any custom headers in allowed_headers.
In Nginx, you can add CORS headers directly in your server block using add_header 'Access-Control-Allow-Origin' 'https://yourapp.com' along with the other required headers for OPTIONS responses.
In AWS API Gateway, enable CORS in the resource settings, which will automatically create the OPTIONS method and populate the required headers. Make sure your Lambda function also returns CORS headers in its response, as API Gateway passes them through.
During local development, you'll often run your frontend on localhost:3000 and your backend on localhost:8000. Even though both are on localhost, different ports make these different origins. Configure your backend to allow http://localhost:3000 explicitly, or use a proxy setup in your bundler (Vite, webpack, etc.) to avoid cross-origin issues entirely during development.
Our CORS Tester is ideal for verifying staging and production API endpoints before deploying your frontend. Enter your production API URL, set your production frontend origin, and confirm that all the required CORS headers are properly configured before your users ever see a CORS error.