CORS Tester
Test and diagnose Cross-Origin Resource Sharing (CORS) headers for any URL
Sample URLs to Test
Understanding CORS
What is CORS?
Cross-Origin Resource Sharing (CORS) is a security mechanism that allows a web page from one origin to request resources from a different origin. Without CORS, browsers block such cross-origin requests by default to prevent security vulnerabilities.
How CORS Works
When a browser makes a cross-origin request, it sends an Origin header. The server must respond with the appropriate Access-Control-Allow-Origin header. For non-simple requests, the browser first sends an OPTIONS preflight request to check if the actual request is permitted.
Key CORS Headers
Access-Control-Allow-Origin specifies allowed origins. Access-Control-Allow-Methods lists allowed HTTP methods. Access-Control-Allow-Headers defines allowed request headers. Access-Control-Allow-Credentials indicates if cookies are permitted.
Debugging CORS Errors
CORS errors appear in the browser console when a cross-origin request is blocked. Check that the server includes the correct CORS headers. For APIs, ensure the server allows your origin, the required methods, and any custom headers you send.
CORS Tester
Test and diagnose Cross-Origin Resource Sharing (CORS) headers for any URL
Features
- Send real HTTP requests to a target URL and inspect CORS-related headers in the response
- Reports Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials, Max-Age
- Tests preflight (OPTIONS) and actual-request behaviour
- Runs in your browser — your request is sent FROM your origin, so the result reflects what your real app would see
- Useful for debugging CORS-blocked production fetches
How to use
- Enter the URL you want to test in the input field or select one of the sample URLs provided for quick testing.
- Choose the HTTP method (GET, POST, etc.) and optionally add custom headers in the advanced options section.
- Click 'Test CORS' to send a cross-origin request and view the detailed results including all CORS headers and their values.
Tips & Best Practices
- Each test sends a real HTTPS request to the target URL — the URL and your IP are visible to the target server.
- CORS is enforced by the browser, not the server. The server sends headers; the browser decides whether to expose the response to JS.
- For wildcard ACAO (`Access-Control-Allow-Origin: *`), the request will succeed but credentials (cookies) won't be sent — that's the spec.
- Preflight (OPTIONS) is sent only for non-simple requests (custom headers, non-GET/POST methods, JSON body in some cases).
- If the test fails, check the browser devtools Network tab — the actual error message is more detailed than this tool can surface.
FAQ
What is CORS and why does it matter for web developers?
CORS (Cross-Origin Resource Sharing) is a browser security feature that controls which web pages can make requests to a different domain than the one that served the page. It matters because modern web applications frequently need to call APIs on different domains, and without proper CORS configuration, these requests will be blocked by the browser. Understanding CORS is essential for building applications that interact with third-party APIs or microservices.
Why do I get a CORS error even though the API works in Postman or curl?
CORS is a browser-enforced security policy, not a server-side restriction. Tools like Postman and curl bypass CORS entirely because they are not browsers and do not enforce the same-origin policy. The browser specifically checks for CORS headers in the server's response and blocks the request if they are missing or incorrect. This is why an API can work perfectly in Postman but fail in a browser application.
What is a preflight request and when does the browser send one?
A preflight request is an OPTIONS request that the browser automatically sends before the actual request to check if the server allows the cross-origin request. The browser sends a preflight for requests that use methods other than GET, HEAD, or POST, or that include custom headers, or that use Content-Type values other than application/x-www-form-urlencoded, multipart/form-data, or text/plain. The server must respond with appropriate CORS headers to allow the actual request to proceed.
What does Access-Control-Allow-Origin: * mean and is it safe?
The wildcard value * means the server allows requests from any origin. While convenient for public APIs, it can be a security risk for private APIs that handle sensitive data. When using *, the server cannot also set Access-Control-Allow-Credentials to true. For APIs that require authentication, you should specify exact allowed origins instead of using the wildcard.
How can I fix CORS errors on my server?
To fix CORS errors, you need to configure your server to include the appropriate CORS headers in its responses. At minimum, add Access-Control-Allow-Origin with either a wildcard (*) or the specific requesting origin. For non-simple requests, also add Access-Control-Allow-Methods and Access-Control-Allow-Headers. Most web frameworks have CORS middleware packages that simplify this configuration, such as cors for Express.js, django-cors-headers for Django, or rack-cors for Ruby on Rails.
Does this tool actually make real cross-origin requests?
Yes, this tool makes real fetch requests from your browser to the URL you specify, which means the browser's CORS policy is fully enforced. If the target server does not include CORS headers, the browser will block the response and the tool will show a CORS blocked status. This gives you an accurate picture of how your browser application would behave when making the same request.