Practical developer guides
cURL works but the browser fails: a CORS debugging checklist
Distinguish network errors from browser CORS policy, inspect preflight requests, and configure allowed origins and credentials deliberately.
First separate the failure layers
cURL is not subject to the browser’s same-origin policy. A successful cURL response can prove that the endpoint responds, but does not establish that a web page is allowed to read it.
In the browser Network panel, distinguish DNS/TLS/connectivity failure, an HTTP error response, and a CORS-blocked response. A generic fetch failure alone does not tell you which one occurred.
Look for the OPTIONS preflight
A cross-origin request with Authorization or an application/json content type commonly triggers an OPTIONS preflight. The server needs to allow the requesting origin, method and requested headers.
Inspect the preflight response as well as the actual response. The headers below are a server configuration example, not instructions to paste into the client request. Only allow the origins your service intends to support.
Access-Control-Allow-Origin: https://tools.nav.city
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Vary: OriginCheck credentials separately
Credentialed browser requests require an explicit allowed origin; Access-Control-Allow-Origin: * cannot be used to expose a credentialed response. The server also needs Access-Control-Allow-Credentials: true, and cookie policies still apply.
Use credentials only when your protocol needs them. Do not reflect any Origin value without checking an allowlist. Cross-origin cookies, mixed content and authentication failures are separate issues to inspect.
Use the right tool for the question
The browser HTTP client sends the request directly to an HTTPS destination when you choose Run. It does not proxy requests or bypass CORS. Use URL Parser to check the address and cURL Converter to prepare a code example.
For an endpoint you own, fix its server policy and test from the intended origin. For a third-party endpoint you cannot change, use an authorized backend integration when appropriate; setting no-cors does not provide a readable response.