CORS preflight debugging should start with the OPTIONS request, not the failed fetch line

CORS preflight debugging should start with the OPTIONS request because the browser may reject the real request before application code sees the response.

MDN describes preflighted requests as browser-issued OPTIONS requests used before certain cross-origin requests. In practice, this means the console error can point at a fetch call while the useful evidence is one network row above it. The actual failing row may be OPTIONS, not the POST or PATCH that the developer expected to inspect.

A practical checklist starts with the request. Is the page origin what the server expects? Is the method simple or does it trigger preflight? Which headers appear in Access-Control-Request-Headers? Is credentials mode involved? Then check the OPTIONS response. Does it return a successful status? Does Access-Control-Allow-Origin match the browser origin or a valid wildcard case? Does Access-Control-Allow-Methods include the actual method? Does Access-Control-Allow-Headers include every requested custom header? If cookies or auth are involved, are credential rules handled consistently?

Next, check the real response. A server can answer OPTIONS correctly and still omit CORS headers on the actual error response. That creates confusion because the API route may work in curl but fail in the browser. The browser cares about the response headers on the path it is allowed to expose, not only whether the backend endpoint can produce JSON.

The debug note should include the full origin, method, requested headers, OPTIONS status, actual status, and which layer generated each response. If a proxy, CDN, or framework middleware handles OPTIONS separately from the route handler, record that too. Most CORS bugs become smaller once OPTIONS and actual request evidence are separated.

CORS preflight debugging should start with the OPTIONS request, not the failed fetch line

// COMMENTS

ON THIS PAGE