CORS Preflight Checker
Describe a cross-origin request and your server's CORS headers to see whether a preflight is sent and exactly which header makes the browser block it.
Free · No sign-up · Your inputs stay in your browser
Input
Check whether a browser will allow a CORS request
The request
The server's response headers
Output
The browser blocks it
Preflight
Yes, OPTIONS first
Non-safelisted: content-type, authorization
With credentials, Access-Control-Allow-Origin may not be *: echo the request's Origin instead. The request sends credentials but the response lacks Access-Control-Allow-Credentials: true. PUT is not in Access-Control-Allow-Methods. authorization is not in Access-Control-Allow-Headers.
A preflight OPTIONS request is sent first unless the request is simple: GET, HEAD or POST, with only CORS-safelisted headers and a form or text/plain content type. A JSON body or an Authorization header always triggers one. CORS is enforced by the browser alone; curl and server-to-server calls ignore it, which is why it works in Postman.
Runs in this browser. Nothing you paste is sent to a server.
About this tool
Method, assumptions, practical next steps, and limits.
The rules most often missed
A JSON body (Content-Type: application/json) or an Authorization header always triggers a preflight. With credentials, Access-Control-Allow-Origin cannot be * and Access-Control-Allow-Credentials must be true; the * wildcards for methods and headers do not apply either, and * never covers Authorization. These rules are in the Fetch standard's CORS protocol.
Why it works in Postman
CORS is enforced by browsers to protect users; curl, Postman and server-to-server calls ignore it. A request that works in Postman and fails in the browser is a CORS configuration problem, never a bug in the endpoint.