TypeError: Failed to fetch — Why fetch() Rejects and How to Fix It

TypeError: Failed to fetch is how Chrome, Edge and other Chromium browsers reject a fetch() promise when no usable response arrived; the string is thrown in Blink's fetch_manager.cc. The same failure reads differently in other engines: Firefox throws TypeError: NetworkError when attempting to fetch resource. (Errors.msg, MSG_FETCH_FAILED), and Safari throws TypeError: Load failed, the sanitized description WebKit gives any failed load.

The Fetch standard turns every failure below HTTP into a single «network error», and a network error rejects the promise with a TypeError (fetch.spec.whatwg.org). A response blocked by CORS is deliberately reported the same way, so a script cannot tell «the server is down» from «the server did not allow your origin». MDN lists the other TypeError reasons: an invalid URL, a URL with a username and password, invalid options, a request blocked by a permissions policy, and no connectivity (MDN: fetch()).

What it is not: an HTTP error. A 404 or 500 resolves the promise normally with response.ok === false. A request you cancelled with AbortController rejects with an AbortError DOMException, not this TypeError.

The JavaScript message is generic on purpose. The browser prints the real reason as a separate line in the DevTools Console, just before the TypeError, and marks the request in the Network tab.

If the request never appears in the Network tab, the browser refused it before sending: an invalid URL, credentials in the URL, a mixed-content block or an extension. If it appears with a status of 200 but the script still gets Failed to fetch, the response arrived and CORS withheld it from the page; that is a server-header problem, not a network one.

Server-side code sees a different text. Node's built-in fetch() comes from undici, which rejects with TypeError: fetch failed and puts the socket-level error in error.cause (undici fetch source). There is no CORS in Node, so the cause is always the network: a refused port, a failed DNS lookup or a connect timeout (undici's connectTimeout defaults to 10 seconds and fails with UND_ERR_CONNECT_TIMEOUT). Log the cause instead of the outer message:

try {
  const res = await fetch('https://api.example.com/v1/items');
} catch (err) {
  console.error(err.message, err.cause?.code, err.cause?.message);
  // fetch failed ECONNREFUSED connect ECONNREFUSED 127.0.0.1:443
}

The code then points to the right page: ECONNREFUSED, getaddrinfo ENOTFOUND or ETIMEDOUT.

1. Read the line above the TypeError. Open DevTools (F12), Console tab, reload, and copy the first red line about the request. It names CORS, mixed content, DNS or a blocked request.
2. Repeat the request outside the browser, with an Origin header. curl does not enforce CORS, so it shows what the server really returns:

   curl -sS -i https://api.example.com/v1/items -H 'Origin: https://app.example.com' | grep -i '^access-control'

   No access-control-allow-origin line, or one with a different origin, means the fix is on the API. Details: blocked by CORS policy.
3. Test the preflight if the request sends JSON, custom headers or a method other than GET, HEAD or POST:

   curl -sS -i -X OPTIONS https://api.example.com/v1/items \
     -H 'Origin: https://app.example.com' \
     -H 'Access-Control-Request-Method: PUT' \
     -H 'Access-Control-Request-Headers: content-type,authorization'

   It must answer with a 2xx status and allow the method and headers.
4. If curl fails too, it is the network. Check name and port: dig +short api.example.com, then curl -v https://api.example.com/. A failed lookup, a refused connection or a certificate error in that output is the real cause.
5. Remove mixed content. A page served over https:// cannot call an http:// API; switch the URL to https:// (see mixed content).
6. Rule out extensions. Retry in a private window with extensions off. Paths such as /ads/, /track or /analytics are common filter-list targets.
7. Handle the failure in code. Distinguish an abort from a network failure so users see a useful message:

   if (err.name === 'AbortError' || err.name === 'TimeoutError') { /* cancelled or AbortSignal.timeout() */ }
   else if (err instanceof TypeError) { /* network or CORS: show offline/retry UI */ }

When a web app shows «Failed to fetch» and you did not write it, the useful checks are short: confirm you are online, reload once, turn off ad blockers or privacy extensions for that site, and disconnect a VPN or corporate proxy that may block the API host. If the app works in another browser or on mobile data, the block is on your device or network. If it fails everywhere, the service is down or misconfigured and only its operator can fix it.

curl -sS -o /dev/null -D - https://api.example.com/v1/items \
  -H 'Origin: https://app.example.com' | grep -i 'access-control-allow-origin'
# access-control-allow-origin: https://app.example.com

Then reload the page with DevTools open: the request should show a normal status in the Network tab and no red CORS or mixed-content line in the Console. To see the CORS answer of any URL, including the preflight, run it through the CORS checker.

• Blocked by CORS policy — the Console line behind most Failed to fetch
• ECONNREFUSED — nothing listening on the API port
• getaddrinfo ENOTFOUND — the API host name does not resolve
• Mixed content — an http:// call from an https:// page
• NET::ERR_CERT_AUTHORITY_INVALID — the API certificate is not trusted
• Fixing CORS preflight — OPTIONS answers step by step