Learn CORSErrorsTesterFrameworksQuizSearch

Why fetch mode: no-cors Does Not Fix a JSON API

By Ankit Jain · Updated

Understand opaque responses and why removing a console error does not make an API response readable.

mode: no-cors does not disable browser security or grant access to a cross-origin API response. It restricts the request and normally gives JavaScript an opaque response.

const response = await fetch('https://api.example.com/data', {
  mode: 'no-cors'
});
console.log(response.type);   // "opaque" for a cross-origin response
console.log(response.status); // 0, not the API’s real HTTP status

What you lose

You cannot read the opaque body, inspect its response headers, or determine its real HTTP status. You also cannot freely use methods and author-controlled headers outside the no-cors request restrictions. Calling response.json() cannot reveal the hidden response.

This mode has legitimate uses where a readable response is unnecessary, including some resource-fetching and caching workflows. It is unsuitable when your app needs API JSON, an error status, or an authentication result.

Fix the permission instead

If you control the API, grant the approved frontend origin access with the appropriate response headers. If you do not, use the API’s supported integration or an authenticated backend you operate. A backend proxy must protect credentials and restrict its destinations; it should not become a public forwarding service.

If fetch rejects rather than returning an opaque response, inspect Network for CORS and network errors. Response types distinguish opaque responses, manual redirects, failed permission, and invalid JSON.

References