How to use this preflight checker
Pick a method, then enter the Content-Type and the header names your own code sets. The tool decides whether an OPTIONS request goes out ahead of the real request. Headers can be one per line or separated by commas, and a Content-Type you enter is counted as a header too. The table lists each header with its safelist status, and the snippet below shows the headers actually exchanged.
What the verdict is based on
It applies the CORS-safelisted definitions from the WHATWG Fetch standard (checked October 2026). The preflight is skipped only when the method is GET, HEAD or POST, the manually set headers are limited to Accept, Accept-Language, Content-Language, Content-Type and Range, and the Content-Type value is one of application/x-www-form-urlencoded, multipart/form-data or text/plain. Authorization is not on that list.
Limits and cautions
The verdict uses only what you enter. No request is sent and no server response is inspected. For headers whose values are constrained, such as Range, only the name is checked and not the value. Settings that are separate from whether a preflight happens, such as credentialed requests or Access-Control-Max-Age, are not covered.
Frequently asked questions
It appears when one of the three conditions breaks. The most common cause is adding an Authorization header, then switching Content-Type to application/json, then changing the method to PUT, PATCH or DELETE. Enter those values above and the broken condition is named for you.
That phrase comes from older CORS documents and the Fetch standard no longer uses it. The standard only defines CORS-safelisted methods and CORS-safelisted request headers, so this tool reports the three conditions separately instead.
No. Headers the browser manages, such as User-Agent and Connection, do not affect the verdict. List only the names your own code sets through setRequestHeader or the headers option of fetch.