How does the fetch API work?

Q: How does the fetch API work?

**Target Audience:** Engineers preparing for JavaScript/browser-API interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every request below was actually made against a real local HTTP server spun up for this verification, not simulated. ## 1. Why This Even Matters — A Story First Calling a delivery company to ask "did my package arrive?" — the phone call itself succeeding (someone answers) is a completely separate thing from the ANSWER being good news. `fetch`'s Promise resolving is exactly like the call being successfully answered — it tells you the network conversation itself completed. Whether the actual news is good (200 OK) or bad (404 Not Found) is a second, separate thing you have to explicitly check by looking at what they actually said, not by whether the call connected at all. ## 2. The Core Idea 📌 **Interview term:** `fetch()` returns a Promise that resolves for

The problem

Question presented to candidate: "If a fetch() call gets back a 404 response from the server, does the returned Promise reject or resolve? Walk me through exactly how you'd correctly handle that case."

What a strong answer should cover:

📌 Interview term: fetch(url, options) — the standard, Promise-based API for making HTTP requests, returning a Promise that resolves to a Response object.
📌 Interview term: the real, direct answer to the prompt — verified directly against a real local server: a genuine 404 response resolves the fetch Promise, not rejects it — response.ok is genuinely false and response.status is genuinely 404, but no error is thrown and no .catch() runs. A precise answer names that correctly handling this requires an explicit check of response.ok (or the specific status code) after the await/.then(), not a try/catch alone.
📌 Interview term: when fetch actually DOES reject — verified directly: only a genuine network-level failure (DNS failure, connection refused, no server listening at all) genuinely rejects the Promise, with a real TypeError — a real, sharp distinction from an HTTP-level error response.
A precise answer names the real steps to read a response body: response.json()/response.text()/response.blob() are themselves also Promise-returning methods (reading the body is an async operation), verified directly with a real JSON body parsed correctly.
A precise answer names that fetch accepts a second options object for method, headers, and body — verified directly with a real POST request carrying a JSON body and a Content-Type header.

Clarifying questions expected:

None — this is a definitional/technical question; directly answering the prompt's own 404-resolves-not-rejects question is the strong signal, since it is the single most commonly misunderstood detail about fetch.

Code / implementation expected: Yes — a real fetch call against a real 404 endpoint, directly observing that it resolves rather than rejects, is the clearest, most convincing demonstration.

fetch

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript/browser-API interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every request below was actually made against a real local HTTP server spun up for this verification, not simulated.

1. Why This Even Matters — A Story First

Calling a delivery company to ask "did my package arrive?" — the phone call itself succeeding (someone answers) is a completely separate thing from the ANSWER being good news. fetch's Promise resolving is exactly like the call being successfully answered — it tells you the network conversation itself completed. Whether the actual news is good (200 OK) or bad (404 Not Found) is a second, separate thing you have to explicitly check by looking at what they actually said, not by whether the call connected at all.

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal proof, against a real live server: a 404 resolves the fetch Promise (check response.ok), only a network failure genuinely rejects