CORS Tester

The CORS tester is a free tool by Corsfix that helps you check whether a given URL supports cross-origin requests or not. You can test any URL for free without registration.

Enter the URL you want to test and the origin making the request, click on the "Test" button, and the tool will show you if the request will succeed or be blocked by CORS. You can also adjust the request method, headers, and body.

CORS (Cross-Origin Resource Sharing) is a browser mechanism that relaxes the Same-Origin Policy to allow controlled access to resources across different domains. By default, browsers enforce the Same-Origin Policy, which blocks requests between different origins. CORS lets servers opt in to allow specific origins to access their resources. For example, if your frontend runs on https://app.example.com and tries to fetch data from https://api.example.com, the browser will block the request unless the API server explicitly allows it via CORS headers. CORS is enforced entirely by the browser — tools like Postman or cURL will never show CORS errors because they don't enforce the Same-Origin Policy.

The CORS tester simulates a real CORS request from a browser environment to the given URL. Unlike backend tools such as Postman or cURL, this tool enforces the Same-Origin Policy, which means if a request fails here, it will also fail for your users in Chrome, Firefox, or Safari. The tool checks the server's response headers to determine whether cross-origin access is allowed.

Enter your API endpoint URL in the "Target URL" field and set the "Origin" to the domain your frontend runs on (e.g., https://myapp.com). Select the HTTP method you plan to use, add any custom headers your API requires, and click "Test". The tool will show you whether the request passes or fails, along with all the CORS headers returned by the server.

If you're testing a simple resource fetch like loading scripts, fonts, or images, use GET. If your frontend sends JSON data or includes custom headers like Authorization, use POST or PUT — the tool will also reveal whether your server correctly handles the preflight OPTIONS request. If you only want to check whether the server allows cross-origin requests without sending an actual request, use OPTIONS directly to inspect the preflight response.

A preflight request is an automatic OPTIONS request that browsers send before certain cross-origin requests. This happens when you use HTTP methods other than GET, HEAD, or POST, or when you include custom headers like Authorization. The preflight asks the server "will you accept this type of request?" and the server responds with its allowed methods and headers. If the preflight fails, the browser will never send the actual request.

To test preflight handling, use a method other than GET (such as POST, PUT, or DELETE) or add a custom header like Authorization. The browser automatically sends an OPTIONS preflight request in these cases. This tool will show you whether your server correctly responds to the preflight with the required Access-Control-Allow-Methods and Access-Control-Allow-Headers headers.

Set the "Origin" to your frontend domain and include a header like Authorization: Bearer your-token in the custom headers section. When credentials are involved, the CORS spec requires the server to return the exact origin (not *) in Access-Control-Allow-Origin and include Access-Control-Allow-Credentials: true. The tool will show you if your server meets these requirements.

Postman is a backend HTTP client that does not enforce the browser's Same-Origin Policy. It sends requests directly to the server without any CORS checks. This tool simulates how a real browser handles cross-origin requests, which is why it reveals CORS blocks that Postman ignores. If your API works in Postman but fails here, your server is missing the required CORS headers.

The tool checks all standard CORS response headers:

• Access-Control-Allow-Origin — Specifies which origin(s) can access the resource. Set to a specific origin or *.
• Access-Control-Allow-Methods — Lists the HTTP methods allowed for cross-origin requests (e.g., GET, POST, PUT).
• Access-Control-Allow-Headers — Specifies which request headers are allowed (e.g., Content-Type, Authorization).
• Access-Control-Allow-Credentials — Set to true to allow cookies and auth headers in cross-origin requests.
• Access-Control-Max-Age — How long (in seconds) the browser can cache the preflight response.
• Access-Control-Expose-Headers — Lists response headers that the browser is allowed to read from JavaScript.

This is the most common CORS error. It means the server did not include the Access-Control-Allow-Origin header in its response. To fix it, configure your server to return this header. Here are examples for popular frameworks:

Node.js (Express):

const cors = require('cors'); // npm install cors
app.use(cors({ origin: 'https://example.com', credentials: true }));

Python (Flask):

from flask_cors import CORS  # pip install flask-cors
CORS(app, origins=['https://example.com'], supports_credentials=True)

PHP:

header("Access-Control-Allow-Origin: https://example.com");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS");
header("Access-Control-Allow-Headers: Content-Type, Authorization");

Java (Spring Boot):

@CrossOrigin(origins = "https://example.com")
@RestController
public class ApiController { }

Ruby on Rails:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://example.com'
    resource '*', headers: :any, methods: [:get, :post, :put, :delete, :options]
  end
end

Nginx:

location /api/ {
    add_header Access-Control-Allow-Origin "https://example.com" always;
    add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;
    add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
    if ($request_method = OPTIONS) { return 204; }
}

When your request includes credentials (cookies, authorization headers), the CORS spec does not allow using a wildcard (*) as the allowed origin. To fix this, replace * with the specific requesting origin (e.g., https://example.com) and add the header Access-Control-Allow-Credentials: true to your server's response.

The browser sent a preflight OPTIONS request, and the server did not list the HTTP method you're using in its Access-Control-Allow-Methods header. To fix this, add the missing method to your server's CORS configuration. For example: Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS.

Your request includes a custom header (like Authorization) that the server hasn't explicitly allowed. Add the header name to the Access-Control-Allow-Headers response header on your server. For example: Access-Control-Allow-Headers: Content-Type, Authorization.

Yes. Set the "Origin" field to your local development URL (e.g., http://localhost:3000 or http://localhost:5173) to simulate how your local frontend will interact with a remote API. This is useful for debugging CORS configuration issues before deploying to production.

If you don't control the server and can't change its CORS headers, the fastest solution is to route your requests through a CORS proxy like Corsfix. The proxy adds the required CORS headers to the response automatically, allowing your frontend to access the resource without errors.