Why can the body of a Response returned by fetch() be read only once — so a second call to response.json() throws — and what do you do when two pieces of code both need that body?

## Bodies are streams, not strings Both `Response` and `Request` expose the same set of body-reading methods, sometimes called the Body mixin: `arrayBuffer()`, `blob()`, `formData()`, `json()` and `text()`. It is tempting to read that list as five different accessors over some stored payload. It is not. There is exactly one payload, exposed as `response.body`, a `ReadableStream`, and every one of those methods is a *consuming* read of it: it locks the stream, drains it to the end, and converts the accumulated bytes into the requested shape. Once that has happened, `response.bodyUsed` is `true` and the stream is spent. A second read — whether it is the same method again or a different one — rejects with a `TypeError`. Browsers phrase it slightly differently ("body stream already read", "Body has already been consumed"), but the cause is identical. ```js const response = await fetch('/api/items'); const text = await response.text(); // drains the stream console.log(response.bodyUsed); // true await response.json(); // TypeError: body already read ``` ## Why the platform does not just buffer everything The body may be a hundred bytes of JSON or a two-gigabyte video, and the browser often does not know which until the bytes stop arriving. If every response were retained so it could be read repeatedly, a page that downloaded a large file would have to hold it entirely in memory even when the code streamed it straight to disk. Making the body one-shot lets the browser hand bytes to the consumer and forget them, which is what makes streaming downloads possible at all. It also removes an ambiguity: with a single-pass stream there is never a question of whether `json()` re-parses the same bytes or re-reads the network. ## clone(), and its cost `response.clone()` produces a second `Response` that reads the same underlying data. The rule is that you must call it *before* the body is touched — calling `clone()` when `bodyUsed` is already `true` throws a `TypeError`. ```js const response = await fetch('/api/items'); const forCache = response.clone(); const data = await response.json(); // one branch parsed await cache.put('/api/items', forCache); // other branch still readable ``` Under the hood the clone tees the stream into two branches. Because the two consumers can read at different speeds, the browser must buffer everything the faster branch has consumed but the slower one has not. A clone that is created and then never read is therefore a memory leak in slow motion: the buffer grows to the whole body and is held until both branches are released. The classic legitimate use is the service worker one — answer the page from the network response and simultaneously put a copy in the `Cache` — and there both branches are consumed promptly. ## The same rule applies to Request A `Request` built with a body behaves identically: it has `bodyUsed`, it is drained when it is sent, and `request.clone()` must be taken while it is still pristine. This is why passing one `Request` object to `fetch()` twice fails on the second call. ## The pattern you should reach for first Most of the time cloning is a workaround for the real problem: reading the body in two places instead of one. Read it once, keep the value, share the value. ```js const response = await fetch(url); const raw = await response.text(); let data; try { data = JSON.parse(raw); } catch { throw new Error(`Non-JSON response (${response.status}): ${raw.slice(0, 200)}`); } ``` This shape also solves a common logging problem. Code that wants to log the raw body *and* parse it does not need `clone()` at all — one `text()` read gives you both, because `JSON.parse` operates on the string you already hold. Reaching for `clone()` there is a sign the reading and the parsing have been split across layers that should have been given the value instead of the `Response`. ## Things that are still fine after a read Only the body is spent. `status`, `ok`, `headers`, `url`, `redirected` and `type` remain readable on a consumed `Response` indefinitely, so an error wrapper can safely read the body and still report the status afterwards.