How does ArrayBuffer transfer and detach work with `transfer()` vs `transferToFixedLength()`?

Q: How does ArrayBuffer transfer and detach work with `transfer()` vs `transferToFixedLength()`?

**Target Audience:** Engineers preparing for JavaScript memory-management interview questions. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every result shown below is **real, captured output** from actually running the code in this doc on Node.js v24.19.0 — not illustrative sample output. ## 1. Why This Even Matters — A Story First Think of an ArrayBuffer as a shipping crate holding raw bytes. Handing it to a Web Worker the slow way means building an identical crate and copying every item into it — two crates now exist, memory usage doubles, and keeping them in sync becomes the caller's problem. transfer() is the "just hand over the same crate" move: ownership moves to a new buffer, the original crate becomes empty and permanently sealed, and not a single byte was copied to make that happen. ## 2. The Core Idea 📌 **Interview term:** a **detached** ArrayBuffer is one whose unde

The problem

Question presented to candidate: "You have an 8-byte ArrayBuffer that a video-processing pipeline needs to hand off to a Web Worker without copying the bytes. Walk me through what buf.transfer() actually does to the original buffer, how it differs from transferToFixedLength(), and what happens if code somewhere still holds a TypedArray view over the original buffer after the transfer."

What a strong answer should cover:

transfer() moves the underlying memory to a brand-new ArrayBuffer and detaches the original in place — the original's byteLength becomes 0 and its detached property becomes true, with no bytes actually copied.
A TypedArray view over a detached buffer does not throw on simple reads: .length and .byteLength silently report 0, and an index read returns undefined. Only a WRITE, such as .set(), throws a TypeError.
transfer(newLength) can also grow (zero-filled) or shrink the buffer as part of the same call — a separate resize() step is not required.
transferToFixedLength() always produces a non-resizable result, even when the source was a resizable ArrayBuffer created with maxByteLength — this is the one concrete behavioral difference from plain transfer(), which preserves the source's resizable-ness and maxByteLength.
Calling transfer() a second time on an already-detached buffer throws a TypeError rather than silently no-oping.
This is the same underlying detach mechanism postMessage/structuredClone have used for years via an explicit transfer list — these methods just expose it as a direct, synchronous API instead of requiring a message-passing round trip.

Clarifying questions expected:

"Does the receiving side need the resizable-ness of the buffer preserved, or is a fixed-length copy acceptable?" — this determines transfer() vs transferToFixedLength().
"Is there code elsewhere holding a TypedArray view over the original buffer that needs a defensive check?" — every existing view over the original becomes a permanently zero-length view immediately after transfer.

Code / implementation expected: Yes — real, executed calls to transfer() and transferToFixedLength() on both plain and resizable ArrayBuffers, showing the actual detached state and a real thrown error, not just a description of the spec.

arraybuffer
transfer
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 JavaScript memory-management interview questions. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every result shown below is real, captured output from actually running the code in this doc on Node.js v24.19.0 — not illustrative sample output.

1. Why This Even Matters — A Story First

Think of an ArrayBuffer as a shipping crate holding raw bytes. Handing it to a Web Worker the slow way means building an identical crate and copying every item into it — two crates now exist, memory usage doubles, and keeping them in sync becomes the caller's problem. transfer() is the "just hand over the same crate" move: ownership moves to a new buffer, the original crate becomes empty and permanently sealed, and not a single byte was copied to make that happen.

The solution is hidden so you can try first

6 min read · 7 sections

Run the code

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

JavaScriptArrayBuffer transfer(), transferToFixedLength(), detach, and error behavior, all genuinely executed (run directly)