What is the difference between readFile and createReadStream in Node.js?

Q: What is the difference between readFile and createReadStream in Node.js?

**Target Audience:** Engineers preparing for Node.js phone screens — assumes very basic `fs` module familiarity. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The numbers below came from **actually reading a real 20MB file** both ways on Node v24.19.0, not a description of expected behavior. ## 1. Why This Even Matters — A Story First Moving a house's contents in one giant crate needs a crane and a truck sized for the entire load at once, delivered all in a single trip. Moving the same contents box by box needs only a normal-sized vehicle, making many smaller trips — slower per trip, but the vehicle never needs to be bigger than one box at a time, no matter how much furniture the house actually holds in total. `readFile` is the giant crate. `createReadStream` is the box-by-box approach. ## 2. The Core Idea 📌 **Interview term: `fs.readFile`** reads a file **entirely into memory**,

The problem

Question presented to candidate: "You need to serve a 2GB video file from an HTTP endpoint. Would you use fs.readFile or fs.createReadStream, and what specifically goes wrong with the other choice?"

What a strong answer should cover:

fs.readFile (and fs.promises.readFile) reads the entire file into memory and delivers it as a single callback/Promise resolution carrying one complete Buffer — simple to use, but memory usage scales directly with file size.
fs.createReadStream reads the file incrementally, delivering it across many smaller chunks (sized by highWaterMark, default 64KB) via 'data' events (or async iteration, or piped directly to a writable) — memory usage stays roughly constant regardless of total file size.
📌 The concrete, measured difference: the identical 20MB file arrived as one readFile callback carrying the full 20MB buffer, versus 320 separate 'data' events from createReadStream with a 64KB highWaterMark — the same total bytes, delivered in a fundamentally different shape.
The practical rule: readFile is fine for files small relative to available memory where the whole content is needed at once anyway (a config file, a small template). createReadStream — usually piped directly to an HTTP response or another writable — is correct for large files, especially ones served over a network, where loading the entire file into memory first is wasteful or outright impossible at scale.
Streaming also enables starting the response before the whole file is read — a client receiving a large file over createReadStream.pipe(res)` starts receiving bytes almost immediately, rather than waiting for the entire file to load into memory first.
A precise answer connects this to backpressure: a stream naturally slows its internal reads to match how fast the destination can consume data (covered fully in the dedicated stream.pipeline()/backpressure questions); readFile has no equivalent concept — it either succeeds with the whole buffer or fails entirely.

Clarifying questions expected:

"How large is the file relative to the process's available memory, and how many concurrent requests need to read it?" — this is the actual deciding factor, not a blanket rule.
"Does the whole file need to be in memory at once for further synchronous processing, or can it be handled chunk by chunk?" — decides whether streaming is even applicable to the use case.

Code / implementation expected: Yes — the measured chunk/callback count difference for the identical file is the concrete, convincing part of the answer.

file-system
streams
memory

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 Node.js phone screens — assumes very basic fs module familiarity. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The numbers below came from actually reading a real 20MB file both ways on Node v24.19.0, not a description of expected behavior.

1. Why This Even Matters — A Story First

Moving a house's contents in one giant crate needs a crane and a truck sized for the entire load at once, delivered all in a single trip. Moving the same contents box by box needs only a normal-sized vehicle, making many smaller trips — slower per trip, but the vehicle never needs to be bigger than one box at a time, no matter how much furniture the house actually holds in total.

readFile is the giant crate. createReadStream is the box-by-box approach.

2. The

The solution is hidden so you can try first

6 min read · 9 sections

Read the code

JavaScriptThe same 20MB file: readFile's single callback vs createReadStream's 320 chunked events, measured

const fs = require("fs");
const BIG = "big2.bin"; // a real 20MB file on disk

fs.readFile(BIG, (err, data) => {
  console.log("readFile callback fired ONCE, length:", data.length);
  // readFile callback fired ONCE with the full buffer, length: 20971520

  let chunks = 0, totalBytes = 0;
  const stream = fs.createReadStream(BIG, { highWaterMark: 64 * 1024 });
  stream.on("data", (chunk) => { chunks++; totalBytes += chunk.length; });
  stream.on("end", () => {
    console.log(`createReadStream delivered ${totalBytes} bytes across ${chunks} events`);
    // createReadStream delivered 20971520 bytes across 320 separate events
  });
});

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.