NetworkError when attempting to fetch resource (Firefox's phrasing; Chrome shows Failed to fetch) is fetch()'s generic failure message for any request that never got a response at all — and its genuine ambiguity is the core challenge: the same message covers CORS rejections, DNS failures, connection refusals, mixed content blocking, and actual network outages.
This error means the fetch() request failed before receiving any HTTP response — critically different from an HTTP error status (404, 500), which is a completed request with an error response; this error means no response was received at all, for one of several genuinely different underlying reasons.
Why This Error Happens
fetch() deliberately gives minimal detail on network-level failures for security reasons (to avoid leaking information to malicious scripts about why a cross-origin request failed). The actual cause is almost always one of: a CORS policy blocking the response from being exposed to your script, the target server being unreachable (DNS failure, connection refused, server down), a mixed-content block (HTTPS page fetching an HTTP resource), or the user's own network connectivity failing mid-request.
Reproducing and Diagnosing the Error
The most common cause in practice — a CORS-blocking response:
fetch("https://api.example.com/data")
.then((res) => res.json())
.catch((err) => console.error(err));
// TypeError: NetworkError when attempting to fetch resource
// (check the Network tab and Console — CORS errors log a specific
// "blocked by CORS policy" message in addition to the generic fetch error)
Diagnosing requires checking the browser console (which often logs a more specific message alongside the generic fetch error) and the Network tab to see whether the request even reached the server:
curl -I https://api.example.com/data
# If this succeeds but fetch() fails, the issue is almost certainly CORS,
# not actual server unavailability
Core Concepts Behind This Error
A CORS rejection and a genuine network failure produce the identical generic fetch() error message, but the browser console usually logs a separate, more specific CORS-related message alongside it — always check the full console output, not just the caught error, since the actual fetch() error object rarely contains enough detail to distinguish the cause on its own.
Mixed content (an HTTPS page fetching an HTTP-only resource) is silently blocked by the browser, producing this same generic error — this is a security policy, not a bug, and the fix is ensuring the resource is served over HTTPS, not working around the block.
DNS failures, connection refusals, and actual offline connectivity all funnel into the same error too — for these causes, the request genuinely never reached any server, distinct from CORS (where the server responded but the browser withheld the response from your script for policy reasons).
Browser extensions and ad blockers can intercept and block specific requests, producing this same error for requests that would otherwise succeed — this is worth checking (via an incognito window with extensions disabled) when the error is inconsistent or environment-specific.
Fixing "NetworkError When Attempting to Fetch Resource"
Fix 1: For CORS-caused failures, fix the server's CORS configuration to allow the requesting origin, since this is a server-side header issue, not something fixable from the client:
// Server-side (Express example) — must explicitly allow the requesting origin
app.use(cors({ origin: "https://yourapp.com", credentials: true }));
Fix 2: For mixed content, ensure all resources are fetched over HTTPS, especially after migrating a site to HTTPS where some hardcoded resource URLs may still use http://:
// Wrong: hardcoded HTTP URL from an HTTPS page — silently blocked
fetch("http://api.example.com/data");
// Fixed: match the page's protocol
fetch("https://api.example.com/data");
Fix 3: For genuine connectivity or server-availability issues, implement retry logic with backoff and surface a clear error state to the user, since these are legitimate transient failures your application should handle gracefully rather than treat as exceptional:
async function fetchWithRetry(url: string, attempts = 3): Promise<Response> {
for (let i = 0; i < attempts; i++) {
try {
return await fetch(url);
} catch (err) {
if (i === attempts - 1) throw err;
await new Promise((r) => setTimeout(r, 2 ** i * 500));
}
}
throw new Error("unreachable");
}
How Do You Tell CORS and a Real Network Failure Apart?
Check the browser console for a specific CORS-related message beyond the generic fetch error — Chrome and Firefox both log a distinct "blocked by CORS policy" line when that's the cause. Also test the same endpoint with curl or Postman (which aren't subject to browser CORS enforcement) — if the request succeeds there but fails in the browser, the cause is almost certainly CORS, not actual server unavailability.
Preventing This Error in Production
Configure CORS deliberately and explicitly on your API server for every origin that legitimately needs access, rather than discovering missing CORS configuration through production errors. Implement retry logic with backoff for genuinely transient network failures, and surface a clear, actionable error state to users rather than letting an unhandled fetch rejection produce a silent or confusing failure.
If you hit this error, check the browser console for a specific CORS message and test the same request outside the browser before assuming it's a general connectivity issue — the two causes need completely different fixes.