Stream a Fetch Response Chunk by Chunk
Process a fetch response as it arrives, chunk by chunk, instead of buffering the whole file in memory. This is ideal for large files like videos or giant JSON datasets.
Why it exists
Web apps often handle large data payloads, like videos or massive API responses. Buffering an entire multi-gigabyte file into memory before processing it is inefficient and can crash the browser tab. Streaming allows you to process data as it arrives over the network, drastically reducing memory usage and improving perceived performance.
The mental model
Think of a ReadableStream as a conveyor belt for data. Instead of waiting for an entire shipment (the full response) to be unloaded before you can inspect it, you can grab items (chunks) off the belt as they pass by. This lets you start working immediately and avoids piling up a huge inventory in your warehouse (the browser's memory).
How it works
The process has three steps. First, you make a request with fetch(). Second, you access the response.body property, which is a ReadableStream. Third, you get a reader with response.body.getReader(). This reader has a .read() method that returns a promise resolving to an object like { value, done }. value is a chunk of data (a Uint8Array), and done is a boolean that's true when the stream is finished. You call .read() in a loop until done is true.
When to use it
Use streaming for any large network response where you can begin work before the entire payload is available. This includes playing large media files, showing download progress indicators, or parsing huge JSON/CSV files without holding the entire string in memory. It's a key technique for building memory-efficient, responsive applications.
When not to use it
For small, predictable API responses, the overhead of stream processing is unnecessary. A simple await response.json() is more straightforward and perfectly fine. Streaming adds complexity, so reserve it for cases where the memory or latency benefits are significant.
One canonical example
To display a download progress bar for a large file, you can fetch it and get the Content-Length header for the total size. Then, create a reader for response.body. Inside your read loop, add the chunk.length to a running receivedLength variable and update your UI by calculating (receivedLength / totalSize) * 100. This gives the user real-time feedback while the download is still in flight.
Interview question
What is the main benefit of processing a Fetch response as a ReadableStream?
- a.It automatically validates the integrity of the received data chunks.
- b.It ensures the entire response is downloaded faster than traditional methods.
- c.It allows for immediate data processing and reduced memory footprint for large files.Correct
- d.It simplifies the handling of small, frequently updated API responses.
Why? this is the answer
The card explicitly states that streaming allows you to "process data as it arrives" and drastically reduces memory usage for large payloads. Option B is incorrect because streaming improves *perceived* performance by enabling early processing, not by making the overall network transfer faster.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #web apis
- #fetch
- #streams
- #performance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on web apis — each one lists the topics its interview covers.
See open roles