Describe the `Buffer` class in Node.js and its use cases.

Q: Describe the `Buffer` class in Node.js and its use cases.

**Target Audience:** Engineers preparing for Node.js interviews — assumes very basic binary-data familiarity. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The copy-vs-view distinction below was **actually verified** on Node v24.19.0 — a real mutation, and a real observed effect (or lack of one), not a description of expected behavior. ## 1. Why This Even Matters — A Story First A photocopy of a document and a sticky note pointing at the original document behave very differently the moment someone writes on them. Scribbling on the photocopy changes nothing about the original filed away in the cabinet. Scribbling directly on the original — even if you were handed it through a folder labeled "your copy" — changes the one and only document everyone else is also looking at. `Buffer.from(buffer)` hands you the photocopy. `.subarray()` hands you the original, through a window. ## 2. Th

The problem

Question presented to candidate: "You call buf.subarray(1, 3) and then mutate a byte in the result. Does the original buffer change too, or is the subarray independent — and how would you actually check?"

What a strong answer should cover:

Buffer is Node's class for handling raw binary data — file contents, network packets, cryptographic material, image/video bytes — anything that is not naturally text, plus text that needs precise control over its byte-level encoding.
Buffers are allocated outside the regular JS object heap (covered with real measured numbers in the dedicated memory-leaks question), which is why they can hold large binary payloads without the overhead of ordinary JS object/array memory management.
📌 The concrete, verifiable distinction the prompt is really asking about: Buffer.from(existingBuffer) copies the bytes into new memory — mutating the copy leaves the original untouched. .subarray(start, end) returns a view into the same underlying memory — mutating the subarray genuinely mutates the original buffer too, verified directly by watching a string actually change.
Buffers support multiple encodings for converting to/from strings — utf8, base64, hex, and others — via .toString(encoding) and Buffer.from(str, encoding), letting the same underlying bytes be represented in whichever text form a given API or protocol expects.
Buffer.concat([...]) joins multiple buffers into one new buffer (a copy, not a view over the inputs) — the standard way to assemble a complete payload from streamed chunks (connecting directly to the dedicated Streams question, where a Readable delivers data across many separate Buffer chunks).
Buffer.alloc/Buffer.allocUnsafe/Buffer.from's specific security and performance trade-offs (zero-filling guarantees, uninitialized memory risk) are covered fully, with real measured timing and a real partial-write demonstration, in their own dedicated question.

Clarifying questions expected:

"Is the concern creating buffers from data, or the copy-vs-view distinction when slicing an existing one?" — the latter is the more commonly misunderstood part.
"Does this buffer hold sensitive data (like a password hash) where the allocation method's zero-filling guarantee actually matters?" — routes to the dedicated alloc/allocUnsafe/from security question.

Code / implementation expected: Yes — actually mutating a .subarray() result and observing the original change (versus Buffer.from(buffer) NOT propagating a mutation) is the concrete, convincing demonstration.

buffer
binary data
streams
performance

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 interviews — assumes very basic binary-data familiarity. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The copy-vs-view distinction below was actually verified on Node v24.19.0 — a real mutation, and a real observed effect (or lack of one), not a description of expected behavior.

1. Why This Even Matters — A Story First

A photocopy of a document and a sticky note pointing at the original document behave very differently the moment someone writes on them. Scribbling on the photocopy changes nothing about the original filed away in the cabinet. Scribbling directly on the original — even if you were handed it through a folder labeled "your copy" — changes the one and only document everyone else is also looking at.

Buffer.from(buffer) han

The solution is hidden so you can try first

6 min read · 9 sections

Read the code

JavaScriptBuffer.from(buffer) copies while subarray() is a view — verified by a real mutation propagating (or not) to the original

const b1 = Buffer.from("hello", "utf8");

const b2 = Buffer.from(b1); // a COPY
b2[0] = 0;
console.log(b1[0], b2[0]); // 104 0 — b1 unaffected

const b3 = b1.subarray(1, 3); // a VIEW into the SAME memory as b1
b3[0] = 90; // ASCII 'Z'
console.log(b1.toString()); // "hZllo" — the ORIGINAL changed

// Encodings and concat:
console.log(Buffer.from("hello").toString("base64")); // aGVsbG8=
console.log(Buffer.from("hello").toString("hex"));      // 68656c6c6f
console.log(Buffer.concat([Buffer.from("foo"), Buffer.from("bar")]).toString()); // foobar

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.