Last month I was debugging a “random” production failure in a browser upload pipeline. The server occasionally rejected a file chunk because a 32-bit length field was wrong—off by exactly 256. Nothing was random: a single byte was being read with the wrong endianness, and the bug only appeared when the chunk boundary landed on a particular offset. That kind of issue is why I keep a tight mental model for JavaScript’s binary primitives.\n\nWhen you work with file formats, network protocols, media containers, WebCrypto, WebGPU/WebCodecs, or WebAssembly, you’re not dealing with strings—you’re dealing with bytes. ArrayBuffer is the foundation: a fixed-length (or optionally resizable) block of raw binary memory. You can’t poke bytes into an ArrayBuffer directly; you attach “views” (TypedArrays or DataView) that interpret the same bytes as numbers.\n\nWhat you’ll get here is a practical reference for ArrayBuffer in modern JavaScript (2026): how to allocate it, inspect it, read/write it correctly, move it across threads, avoid the classic footguns, and choose between TypedArray and DataView based on real workloads.\n\n## ArrayBuffer: the bytes, and only the bytes\nThink of an ArrayBuffer as a sealed box of memory. The box has a size in bytes. That’s it. No element type. No endianness. No notion of “index 3 means the 4th number.” Those concepts come from views.\n\n- ArrayBuffer = the storage (raw bytes)\n- TypedArray (like Uint8Array, Float32Array) = a view that interprets bytes as a packed array of a specific numeric type\n- DataView = a view that reads/writes numbers at arbitrary byte offsets, with explicit endianness per operation\n\nA small analogy I use: the buffer is a sheet of graph paper. A TypedArray is a ruler that marks every 2 squares as “one unit” (e.g., Uint16Array) starting from the beginning. A DataView is a magnifying glass that lets you point at any square and decide how to interpret the next 2/4/8 squares.\n\n### Syntax, parameter, return\nArrayBuffer is created with new:\n\n new ArrayBuffer(byteLen)\n\n- byteLen (number): the total number of bytes to allocate.\n- Return: an ArrayBuffer instance.\n\n### Baseline example: create a buffer and attach a typed view\nHere’s the canonical “hello bytes” example. The Int32Array view interprets the same 8 bytes as two signed 32-bit integers.\n\n
const buffer = new ArrayBuffer(8);\nconst view = new Int32Array(buffer);\nconsole.log(view);\n// Expected output shape: Int32Array(2) [ 0, 0 ]\n\n\nThose zeros aren’t “special”—newly allocated buffers are typically zero-filled in JavaScript environments.\n\n### My mental checklist (the stuff I repeat to myself)\nBefore I write a single getUint32, I force myself to answer these questions explicitly:\n\n1) What are the units? Bytes or elements?\n2) What’s the endianness of each multi-byte field?\n3) Are offsets absolute or relative to a sub-slice?\n4) Is this code allowed to copy, or must it be zero/low-copy?\n5) Who owns the memory after I send it somewhere (worker, WASM, socket)?\n\nIf you can answer those five, you avoid most production bugs I’ve seen in binary JS.\n\n## Allocation strategies in 2026: fixed vs resizable buffers\nThe classic ArrayBuffer(byteLen) gives you a fixed-length buffer. That’s perfect for most parsing and encoding tasks. But modern runtimes also support resizable buffers (where the buffer can grow or shrink up to a declared maximum).\n\n### Fixed-length allocation\nUse fixed buffers when:\n- You know the size up front (file headers, fixed packets, crypto inputs)\n- You want stable references and predictable bounds\n- You want fewer feature-detection branches\n\n
// 64 KiB scratch space for parsing chunks\nconst scratch = new ArrayBuffer(64 1024);\nconst bytes = new Uint8Array(scratch);\n\n\n### Resizable allocation (when supported)\nResizable buffers shine when you build binary data incrementally (encoders, streaming assemblers), and you want to avoid repeated reallocations.\n\nKey points I recommend you internalize:\n- Resizing is only possible if the buffer was created as resizable with a maxByteLength.\n- Views may become out-of-date after a resize in ways that surprise people. In practice, I treat “resize” as a moment where I recreate my views.\n- Always feature-detect; don’t assume every embedded runtime has it.\n\n
function supportsResizableArrayBuffer() {\n try {\n // If this throws or the property is missing, treat as unsupported.\n const b = new ArrayBuffer(8, { maxByteLength: 32 });\n return typeof b.resize === "function" && typeof b.maxByteLength === "number";\n } catch {\n return false;\n }\n}\n\nif (supportsResizableArrayBuffer()) {\n const buffer = new ArrayBuffer(8, { maxByteLength: 1024 });\n console.log(buffer.byteLength); // 8\n console.log(buffer.maxByteLength); // 1024\n console.log(buffer.resizable); // true (in supporting runtimes)\n\n buffer.resize(64);\n console.log(buffer.byteLength); // 64\n}\n\n\nIf you’re writing a library, my rule is: accept either fixed or resizable ArrayBuffer inputs, but avoid making resizable buffers a requirement unless the value is overwhelming.\n\n### Resizing footguns (what I personally guard against)\nResizable buffers are powerful, but they demand a few habits:\n\n- I never stash a Uint8Array view and assume it stays valid after resize. I rebuild it.\n- I never trust “length” variables that were computed before resize. I recompute bounds from buffer.byteLength.\n- I isolate resizing into a tiny function, so the rest of the code treats the buffer as effectively immutable.\n\nIf you’re thinking “this sounds annoying,” you’re right—and that’s exactly why fixed-length buffers remain the default for most production code.\n\n## TypedArray vs DataView: how I choose in real code\nThis is the decision that affects correctness more than performance.\n\n### TypedArrays: fast, vector-like, great for bulk operations\nUse a TypedArray when:\n- Your data is naturally a uniform array of numbers (samples, pixels, indices)\n- You want bulk operations (copying, slicing, iteration)\n- You’re okay with the view’s element alignment and fixed stride\n\n
// Interpret 16 bytes as four unsigned 32-bit integers\nconst buffer = new ArrayBuffer(16);\nconst u32 = new Uint32Array(buffer);\n\nu32[0] = 0x11223344;\nu32[1] = 0xAABBCCDD;\nconsole.log(u32.length); // 4\n\n\nImportant nuance: TypedArrays use the platform’s endianness when they map multi-byte values. On mainstream hardware you’ll usually be little-endian, but if you need portable, explicit endianness (protocols, file formats), I reach for DataView.\n\n### DataView: precise offsets + explicit endianness\nUse DataView when:\n- You’re parsing a structured binary format (headers, records, tagged fields)\n- You need mixed types at arbitrary byte offsets\n- Endianness must be explicit and correct\n\n
// Parse a tiny binary header:\n// offset 0: uint32 magic (big-endian)\n// offset 4: uint16 version (big-endian)\n// offset 6: uint16 flags (big-endian)\n\nconst buffer = new ArrayBuffer(8);\nconst dv = new DataView(buffer);\n\n// Write values (big-endian => littleEndian=false)\ndv.setUint32(0, 0x4D534746, false); // "MSGF" in ASCII-ish\nDVsetU16(dv, 4, 3);\nDVsetU16(dv, 6, 0b00000011);\n\nfunction DVsetU16(view, offset, value) {\n view.setUint16(offset, value, false);\n}\n\nconst magic = dv.getUint32(0, false);\nconst version = dv.getUint16(4, false);\nconst flags = dv.getUint16(6, false);\n\nconsole.log({ magic: magic.toString(16), version, flags });\n\n\nIf you only remember one thing: DataView is the “protocol correctness” tool.\n\n### A practical middle-ground I use constantly\nA pattern I rely on is: DataView for the header, Uint8Array for the payload.\n\n- Headers are where endianness and offsets matter.\n- Payload is often just bytes (or a separate typed array) and benefits from bulk copies.\n\nOnce you internalize that split, most code becomes cleaner.\n\n## Views, offsets, and alignment (the part that silently breaks things)\nBinary bugs love to hide in the difference between byteOffset and “offset into my logical message.” I treat these as two different coordinate systems.\n\n### The three numbers every view carries\nEvery TypedArray and DataView has:\n\n- .buffer (the underlying ArrayBuffer)\n- .byteOffset (where this view starts inside the buffer)\n- .byteLength (how many bytes this view spans)\n\nTypedArrays additionally have:\n\n- .length (element count)\n- .BYTESPERELEMENT (element size)\n\nA lot of “it works locally but fails in prod” bugs come from code that uses .buffer and ignores .byteOffset.\n\n### Example: the subarray trap\nIf I take a slice of a Uint8Array using .subarray, I get a view into the same buffer. That’s what I want for performance—but it means you must preserve offset/length.\n\n
const whole = new Uint8Array([1, 2, 3, 4, 5]);\nconst part = whole.subarray(2, 4); // [3,4]\n\nconsole.log(part.buffer === whole.buffer); // true\nconsole.log(part.byteOffset); // not 0\n\n// Wrong: new Uint8Array(part.buffer) includes the entire original buffer\n// Right: respect byteOffset/byteLength\nconst normalized = new Uint8Array(part.buffer, part.byteOffset, part.byteLength);\nconsole.log(Array.from(normalized)); // [3,4]\n\n\nWhen I write library code, I almost always normalize inputs into a Uint8Array window of the intended bytes (preserving offset and length).\n\n### Alignment: when TypedArrays refuse to cooperate\nTypedArrays have implicit alignment: a Uint32Array view expects its start offset to be a multiple of 4. If you try to create it with a misaligned offset, you’ll get a RangeError.\n\nThat’s one reason DataView exists: it can read/write multi-byte values at arbitrary offsets. When I parse formats with odd offsets (yes, they exist), I use DataView for the misaligned fields.\n\n## Endianness: not hard, just unforgiving\nEndianness is one of those concepts people “know,” but then forget to encode into the code. My rule: if bytes cross a boundary (network, file, IPC), I treat endianness as part of the contract and I spell it out every time.\n\n### What I do in practice\n- Network protocols: typically big-endian (a.k.a. “network byte order”).\n- Many file formats: often big-endian in headers, sometimes mixed.\n- Most CPUs you’ll run JS on: little-endian, which makes TypedArrays feel fine—until you run into a spec that mandates big-endian.\n\n### Explicit helpers reduce errors\nI like writing tiny helpers so I don’t accidentally flip the littleEndian boolean halfway through a file parser.\n\n
function readU32BE(dv, offset) {\n return dv.getUint32(offset, false);\n}\n\nfunction writeU32BE(dv, offset, value) {\n dv.setUint32(offset, value, false);\n}\n\nfunction readU16LE(dv, offset) {\n return dv.getUint16(offset, true);\n}\n\n\nI’m not trying to be fancy here—just trying to make it difficult to do the wrong thing.\n\n## Copying, slicing, and transferring: controlling ownership and cost\nBinary work becomes painful when you accidentally copy megabytes.\n\n### slice() makes a new ArrayBuffer\nbuffer.slice(start, end) returns a new ArrayBuffer containing a copy of bytes from the original.\n\n
const original = new ArrayBuffer(10);\nconst bytes = new Uint8Array(original);\nbytes.set([10, 20, 30, 40, 50], 0);\n\nconst copy = original.slice(1, 4); // bytes 1..3\nconsole.log(Array.from(new Uint8Array(copy))); // [20, 30, 40]\n\n\nI like slice() when:\n- I need an immutable snapshot of a subrange\n- I’m about to hand data to code I don’t fully trust\n\nIf you want a view without copying, use a TypedArray with byteOffset and byteLength.\n\n
const buffer = new ArrayBuffer(10);\nconst bytes = new Uint8Array(buffer);\nbytes.set([10, 20, 30, 40, 50], 0);\n\n// View the subrange without copying\nconst windowView = new Uint8Array(buffer, 1, 3);\nconsole.log(Array.from(windowView)); // [20, 30, 40]\n\n\n### Transfer vs clone (workers and structured cloning)\nWhen you send an ArrayBuffer to a Web Worker (or between threads in other JS runtimes), you typically have two choices:\n- Clone (copy the bytes)\n- Transfer (move ownership, usually zero-copy)\n\nTransfer is what I default to for large payloads because it avoids the cost of duplicating memory.\n\n
// Browser example: transferring a buffer to a worker\n// main.js\nconst worker = new Worker("worker.js", { type: "module" });\nconst buffer = new ArrayBuffer(1024 1024); // 1 MiB\n\nworker.postMessage({ buffer }, [buffer]);\nconsole.log(buffer.byteLength); // Often becomes 0 after transfer (detached)\n\n\nDetached buffers are a feature, not a bug: they prevent you from accidentally mutating memory you no longer own.\n\nIf you need shared memory, that’s a different tool: SharedArrayBuffer. It comes with security requirements in browsers (cross-origin isolation headers), and I only recommend it when you genuinely need concurrent reads/writes with Atomics.\n\n### structuredClone with transfer (a nice ergonomic option)\nIn environments that support it, structuredClone(value, { transfer: [...] }) is a clean way to make your transfer intent explicit. I like it because it reads like “clone, but move these buffers.”\n\n
const buffer = new ArrayBuffer(1024);\nconst payload = { kind: "chunk", buffer };\n\nconst moved = structuredClone(payload, { transfer: [buffer] });\n// buffer is typically detached after this\n\n\nI don’t rely on this everywhere (feature-detect if you’re targeting older runtimes), but it’s a good tool to keep in mind.\n\n## Reference: constructor, properties, and methods\nThis is the quick “what exists” map I keep in my head.\n\n### Constructor\n
What it does
—
\n
new ArrayBuffer(byteLen) Allocates an ArrayBuffer with byteLen bytes
Property
\n
—
buffer.constructor
\n
buffer.byteLength Current length (in bytes)
buffer.maxByteLength
\n
buffer.resizable Boolean indicating whether resizing is allowed
byteLength is always safe to read and should be your first bounds check.\n- maxByteLength and resizable are most useful behind feature detection.\n\n### Static methods\nStatic method
\n
—
ArrayBuffer.isView(value)
true if value is a view on an ArrayBuffer (TypedArray or DataView) \n\nI use isView to validate inputs where callers might pass Uint8Array instead of ArrayBuffer.\n\n
function normalizeToUint8Array(input) {\n if (input instanceof ArrayBuffer) return new Uint8Array(input);\n if (ArrayBuffer.isView(input)) {\n return new Uint8Array(input.buffer, input.byteOffset, input.byteLength);\n }\n throw new TypeError("Expected ArrayBuffer or view");\n}\n\n\n### Instance methods\n
Meaning
—
\n
buffer.resize(newByteLength) Resizes the buffer if it was created as resizable and within maxByteLength
buffer.slice(begin, end)
ArrayBuffer with copied bytes from the given range \n\n## Practical recipes I actually ship\nI’m going to keep these examples runnable and focused on patterns you’ll reuse.\n\n### 1) Build a binary message with an explicit layout\nScenario: you need to send a message over WebSocket or a custom transport.\n\nLayout (all big-endian):\n- 0..3: uint32 message type\n- 4..7: uint32 request id\n- 8..9: uint16 payload length\n- 10..: payload bytes (UTF-8)\n\n
// Works in modern browsers and Node.js (TextEncoder available)\nconst encoder = new TextEncoder();\n\nfunction buildMessage({ type, requestId, text }) {\n const payload = encoder.encode(text);\n if (payload.byteLength > 65535) throw new RangeError("Payload too large");\n\n const headerSize = 10;\n const buffer = new ArrayBuffer(headerSize + payload.byteLength);\n const dv = new DataView(buffer);\n\n dv.setUint32(0, type, false);\n dv.setUint32(4, requestId, false);\n dv.setUint16(8, payload.byteLength, false);\n\n new Uint8Array(buffer, headerSize).set(payload);\n return buffer;\n}\n\nconst msg = buildMessage({ type: 7, requestId: 1042, text: "status=ok" });\nconsole.log(msg.byteLength);\n\n\nWhy I like this pattern:\n- DataView handles multi-byte fields cleanly with explicit endianness.\n- Uint8Array(...).set(...) copies payload bytes efficiently.\n\n### 2) Parse a binary message safely (bounds checks first)\nMost real bugs are missing bounds checks.\n\n
const decoder = new TextDecoder();\n\nfunction parseMessage(buffer) {\n if (!(buffer instanceof ArrayBuffer)) throw new TypeError("Expected ArrayBuffer");\n if (buffer.byteLength < 10) throw new RangeError("Message too small");\n\n const dv = new DataView(buffer);\n const type = dv.getUint32(0, false);\n const requestId = dv.getUint32(4, false);\n const payloadLen = dv.getUint16(8, false);\n\n const headerSize = 10;\n const end = headerSize + payloadLen;\n if (end > buffer.byteLength) throw new RangeError("Truncated payload");\n\n const payloadBytes = new Uint8Array(buffer, headerSize, payloadLen);\n const text = decoder.decode(payloadBytes);\n\n return { type, requestId, text };\n}\n\nconst parsed = parseMessage(msg);\nconsole.log(parsed);\n\n\n### 3) Read a file slice without loading everything into JS memory\nIn browsers, Blob.arrayBuffer() is common. But for very large files, you should slice.\n\n
async function readFileHeader(file) {\n // Read the first 64 bytes only\n const headerBlob = file.slice(0, 64);\n const buffer = await headerBlob.arrayBuffer();\n const bytes = new Uint8Array(buffer);\n\n // Example check: first four bytes as ASCII\n const signature = String.fromCharCode(bytes[0], bytes[1], bytes[2], bytes[3]);\n return { signature, bytes };\n}\n\n\nI’ve seen teams accidentally call arrayBuffer() on multi-gigabyte uploads and wonder why memory spikes.\n\n### 4) A safe “cursor” reader for binary parsing\nWhen I parse real formats, I rarely use raw offsets everywhere. I use a cursor object that tracks position and performs bounds checks. It’s a small abstraction that pays for itself immediately.\n\n
function makeReader(buffer, { littleEndian = false } = {}) {\n if (!(buffer instanceof ArrayBuffer)) throw new TypeError("Expected ArrayBuffer");\n\n const dv = new DataView(buffer);\n let off = 0;\n\n function ensure(n) {\n if (off + n > buffer.byteLength) {\n throw new RangeError(Need ${n} bytes at offset ${off}, have ${buffer.byteLength});\n }\n }\n\n return {\n get offset() { return off; },\n seek(newOffset) {\n if (newOffset < 0 newOffset > buffer.byteLength) throw new RangeError("Bad offset");\n off = newOffset;\n },\n skip(n) { ensure(n); off += n; },\n u8() { ensure(1); const v = dv.getUint8(off); off += 1; return v; },\n u16() { ensure(2); const v = dv.getUint16(off, littleEndian); off += 2; return v; },\n u32() { ensure(4); const v = dv.getUint32(off, littleEndian); off += 4; return v; },\n bytes(n) {\n ensure(n);\n const view = new Uint8Array(buffer, off, n);\n off += n;\n return view;\n },\n };\n}\n
\n\nI like this approach because it centralizes correctness. Instead of sprinkling “if (end > byteLength)” throughout a parser, I enforce it in one place.\n\n### 5) Writing with a growable builder (without resizable buffers)\nEven if you can’t rely on resizable ArrayBuffer, you can still build efficiently by chunking. I often do this for encoders that don’t know the final size up front.\n\n
function makeByteBuilder(chunkSize = 4096) {\n let chunks = [];\n let cur = new Uint8Array(chunkSize);\n let used = 0;\n\n function pushByte(b) {\n if (used === cur.length) {\n chunks.push(cur);\n cur = new Uint8Array(chunkSize);\n used = 0;\n }\n cur[used++] = b & 0xff;\n }\n\n function pushBytes(bytes) {\n for (let i = 0; i < bytes.length; i++) pushByte(bytes[i]);\n }\n\n function finish() {\n const last = cur.subarray(0, used);\n const total = chunks.reduce((n, c) => n + c.length, 0) + last.length;\n\n const out = new Uint8Array(total);\n let o = 0;\n for (const c of chunks) { out.set(c, o); o += c.length; }\n out.set(last, o);\n return out.buffer;\n }\n\n return { pushByte, pushBytes, finish };\n}\n
\n\nThis isn’t theoretical—it’s a pattern that keeps encoders simple and avoids quadratic “reallocate and copy” behavior.\n\n## Text and bytes: UTF-8, ASCII, and the real world\nA lot of code treats strings like they’re bytes, and that’s where corruption starts. JavaScript strings are sequences of UTF-16 code units, not bytes. If you need bytes, use TextEncoder/TextDecoder.\n\n### Encoding and decoding correctly\n
const enc = new TextEncoder();\nconst dec = new TextDecoder("utf-8", { fatal: false });\n\nconst bytes = enc.encode("café");\nconsole.log(bytes);\n\nconst str = dec.decode(bytes);\nconsole.log(str);\n
\n\n### Common pitfalls I’ve debugged\n- “String length” is not “byte length.” "✅".length is not 1 byte and not even 1 code point in simple terms.\n- Naively using charCodeAt and stuffing values into bytes will destroy non-ASCII text.\n- Assuming “header is 10 bytes” and then writing a JS string into it without encoding leads to misaligned payloads.\n\n### ASCII-only shortcuts (only when you truly mean ASCII)\nIf your protocol guarantees ASCII (like some legacy headers), you can implement a fast path—but I do it with guardrails.\n\n
function writeAscii(bytes, offset, s) {\n for (let i = 0; i < s.length; i++) {\n const c = s.charCodeAt(i);\n if (c > 0x7f) throw new RangeError("Non-ASCII char");\n bytes[offset + i] = c;\n }\n}\n
\n\nIf there’s any chance of non-ASCII data, I stick to TextEncoder. It’s not worth the future bug.\n\n## Node.js interop: Buffer and ArrayBuffer without surprises\nIf you touch server-side JavaScript, you will run into Buffer. The good news is: modern Node makes interop pretty smooth. The bad news is: it’s easy to accidentally include extra bytes if you ignore offsets.\n\n### The rule I follow\nWhen converting a Buffer to a Uint8Array view of exactly the intended bytes, I preserve byteOffset/byteLength just like any other view.\n\n
function bufferToU8(buf) {\n // buf is a Node.js Buffer (a Uint8Array subclass)\n return new Uint8Array(buf.buffer, buf.byteOffset, buf.byteLength);\n}\n
\n\n### When you actually need a standalone ArrayBuffer\nSometimes you want an ArrayBuffer that owns only those bytes (for example, you want to transfer it or you want to guarantee it doesn’t reference a larger pooled slab). In that case, I explicitly copy.\n\n
function toOwnedArrayBuffer(view) {\n const u8 = ArrayBuffer.isView(view) ? new Uint8Array(view.buffer, view.byteOffset, view.byteLength)\n : new Uint8Array(view);\n return u8.slice().buffer; // copy into a new Uint8Array, then take its buffer\n}\n
\n\nThe key is being intentional: “view” and “owned copy” are both valid, but mixing them accidentally is where bugs happen.\n\n## Working with streams: ArrayBuffer in a chunked world\nA lot of modern APIs are stream-first (fetch bodies, file reads, media pipelines). That changes how you think about buffers: you’re usually handling chunks (Uint8Array) rather than one monolithic ArrayBuffer.\n\n### Streaming parse pattern (incremental framing)\nA very common real-world job: take a stream of bytes and extract framed messages with a length prefix. The tricky part is messages may split across chunk boundaries.\n\nHere’s a pragmatic approach I use: keep a rolling Uint8Array “stash,” append new chunks, and peel off complete frames.\n\n
function concatU8(a, b) {\n const out = new Uint8Array(a.length + b.length);\n out.set(a, 0);\n out.set(b, a.length);\n return out;\n}\n\n// Frame format: [u32be length][payload bytes...]\nfunction* extractFramesFromStash(stash) {\n let offset = 0;\n const dv = new DataView(stash.buffer, stash.byteOffset, stash.byteLength);\n\n while (stash.length - offset >= 4) {\n const len = dv.getUint32(offset, false);\n const need = 4 + len;\n if (stash.length - offset < need) break;\n\n const payload = stash.subarray(offset + 4, offset + need);\n yield payload;\n offset += need;\n }\n\n return stash.subarray(offset);\n}\n\nasync function parseFramedStream(readableStream) {\n const reader = readableStream.getReader();\n let stash = new Uint8Array(0);\n\n while (true) {\n const { value, done } = await reader.read();\n if (done) break;\n stash = concatU8(stash, value);\n\n const it = extractFramesFromStash(stash);\n let r = it.next();\n while (!r.done) {\n const payload = r.value;\n // process payload (Uint8Array view)\n r = it.next();\n }\n stash = r.value;\n }\n\n if (stash.length !== 0) {\n throw new RangeError("Trailing incomplete frame");\n }\n}\n
\n\nThis is not the most allocation-free thing in the universe, but it’s clear and correct—and clarity matters when you’re dealing with framing bugs. If it becomes a hotspot, I optimize by using a ring buffer or chunk list, but I don’t start there.\n\n### Fetch response: getting bytes responsibly\nI’m careful with .arrayBuffer() on large responses. If I need the whole payload (and I know it’s bounded), fine. If it can be large or untrusted, I stream and enforce limits.\n\nA practical safety limit pattern I use:\n\n
async function readAllBytesWithLimit(readableStream, maxBytes) {\n const reader = readableStream.getReader();\n let chunks = [];\n let total = 0;\n\n while (true) {\n const { value, done } = await reader.read();\n if (done) break;\n\n total += value.byteLength;\n if (total > maxBytes) throw new RangeError("Body too large");\n\n chunks.push(value);\n }\n\n const out = new Uint8Array(total);\n let o = 0;\n for (const c of chunks) { out.set(c, o); o += c.byteLength; }\n return out.buffer;\n}\n
\n\nI like this because it’s explicit about the “DoS shape” of the code.\n\n## SharedArrayBuffer and Atomics (only when you really need them)\nMost apps do not need shared memory. But when you do—audio pipelines, concurrent decoders, real-time analytics—it’s powerful.\n\n### The conceptual difference\n- ArrayBuffer: owned by one agent at a time (or cloned). You can transfer ownership, but you can’t safely mutate from multiple threads.\n- SharedArrayBuffer: multiple agents can read/write concurrently. Coordination requires Atomics to avoid data races.\n\n### A tiny ring-buffer sketch\nThis isn’t a full implementation, but it shows the idea: a shared byte region plus shared indices.\n\n
// Shared layout (conceptual):\n// 0..3: writeIndex (i32)\n// 4..7: readIndex (i32)\n// 8.. : data bytes\n\nfunction makeSharedQueue(capacity) {\n const sab = new SharedArrayBuffer(8 + capacity);\n const idx = new Int32Array(sab, 0, 2);\n const data = new Uint8Array(sab, 8);\n return { sab, idx, data };\n}\n
\n\nIn practice, you’d use Atomics.load/store and often Atomics.wait/notify (where available) to coordinate. I’m mentioning this mainly so you know where ArrayBuffer ends and the next tool begins.\n\n## WebAssembly: ArrayBuffer as the bridge to linear memory\nWhen you interact with WebAssembly, you usually deal with a WebAssembly.Memory whose .buffer is an ArrayBuffer. That can be a huge win (direct, low-level interop), but it has the same “views might become stale” pitfall when memory grows.\n\n### The practical pitfall\nIf WASM memory grows, the underlying memory.buffer can change identity. Any TypedArray you created earlier may now point at the old buffer. The safe habit: create views when you need them, or recreate after a grow event/operation.\n\nA pattern I like is to wrap access in a function that always reads memory.buffer fresh.\n\n
function makeWasmU8(memory, ptr, len) {\n return new Uint8Array(memory.buffer, ptr, len);\n}\n
\n\n## Debugging tools I keep in my pocket\nBinary debugging is miserable if you can’t see the bytes. I keep two utilities around: a hexdump and a “read fields” logger.\n\n### Hexdump (small, readable, good enough)\n
function hex(u8, { start = 0, end = u8.length, width = 16 } = {}) {\n const slice = u8.subarray(start, end);\n let out = "";\n\n for (let i = 0; i < slice.length; i += width) {\n const row = slice.subarray(i, i + width);\n const addr = (start + i).toString(16).padStart(8, "0");\n\n let bytes = "";\n let ascii = "";\n for (let j = 0; j < width; j++) {\n if (j < row.length) {\n const b = row[j];\n bytes += b.toString(16).padStart(2, "0") + " ";\n ascii += b >= 0x20 && b <= 0x7e ? String.fromCharCode(b) : ".";\n } else {\n bytes += " ";\n ascii += " ";\n }\n }\n\n out += ${addr} ${bytes}
${ascii}\n;\n }\n\n return out;\n}\n\n\nI don’t print huge dumps in production logs, but for debugging a corrupt header, this is priceless.\n\n### The fastest way I find endianness bugs\nWhen a 32-bit value is wrong, I look at the same 4 bytes in both endian interpretations.\n\n
function inspectU32(dv, offset) {\n const be = dv.getUint32(offset, false);\n const le = dv.getUint32(offset, true);\n return { be, le, beHex: be.toString(16), leHex: le.toString(16) };\n}\n\n\nIf one of those matches what I expect, I’ve located the contract mismatch instantly.\n\n## Performance considerations (without cargo-culting)\nI care about performance when binary code sits on a hot path: media, crypto, compression, real-time messaging, big file uploads. But I don’t prematurely optimize. I aim for two things: avoid accidental copies, and avoid needless allocations.\n\n### My “copy budget” rules of thumb\n- Avoid converting Uint8Array to JS arrays except for debugging.\n- Avoid .slice() in loops unless you truly need a copy.\n- Use windowed views (new Uint8Array(buffer, offset, len) or .subarray) to avoid copies.\n- Prefer building output into a pre-sized buffer when you know the final size.\n\n### Pooling and reuse\nFor repeated parsing of similarly sized chunks (like upload parts), I often keep a fixed scratch ArrayBuffer and reuse it. This reduces GC pressure and keeps latency flatter.\n\nThe important caveat: if you return slices/views of your scratch buffer to callers, you must either (a) document that data is only valid until the next call, or (b) copy when handing out results. Most library APIs should copy; most internal pipelines can safely reuse.\n\n### Measure with the simplest possible harness\nIf I’m unsure whether a copy matters, I measure with performance.now() (browser) or similar timing APIs. I avoid microbench fantasies and instead benchmark the actual sizes and operations my app does (for example: 64 KiB chunks, 1 MiB frames, 10-byte headers at 50k/sec).\n\n## Common mistakes I keep seeing (and how I prevent them)\n### Mistake 1: Confusing bytes with elements\nUint32Array(buffer).length is measured in 32-bit elements, not bytes. If you need bytes, use buffer.byteLength or a Uint8Array.\n\nMy habit: I name variables byteLength, offsetBytes, payloadBytes to keep units explicit.\n\n### Mistake 2: Endianness assumptions\nIf you parse a network protocol or a file format, you should assume endianness matters.\n\nMy rule:\n- For structured formats: use DataView and pass the littleEndian flag explicitly every time.\n- For bulk numeric arrays you control end-to-end: TypedArrays are fine.\n\n### Mistake 3: Ignoring byteOffset when normalizing views\nIf someone passes you a Uint8Array that points into the middle of a larger buffer, input.buffer alone is not the data they intended.\n\nUse input.byteOffset and input.byteLength when wrapping.\n\n### Mistake 4: Accidental copies in hot paths\nslice() copies. Array.from(typedArray) copies. Spreading ([...typedArray]) copies.\n\nIn hot code, I keep data in Uint8Array and only convert to JS arrays for logging or debugging.\n\n### Mistake 5: Integer overflow and length-trust\nJavaScript numbers are floating-point. While typed reads give you correct integer values, it’s still easy to do unsafe math like offset + len without validating that len is reasonable. If len comes from untrusted input (network/file), I enforce hard upper bounds early.\n\nThis is both a correctness issue and a security issue: “allocate length from input” is a classic memory-exhaustion attack.\n\n### Mistake 6: Detached buffers after transfer\nIf you transfer an ArrayBuffer, it’s often detached (its byteLength becomes 0). Code that tries to keep using it will fail in confusing ways. My rule: after a transfer, I never touch the original variable again. I treat it as “moved.”\n\n## When you should (and shouldn’t) reach for ArrayBuffer\nI recommend ArrayBuffer when:\n- You’re interfacing with platform APIs that speak bytes (fetch streams, crypto, codecs, wasm)\n- You need deterministic layouts and compact storage\n- You care about throughput and GC pressure (large strings and objects get expensive)\n\nI recommend you avoid it when:\n- Your data is naturally text and you don’t need a binary protocol\n- You’re doing small, infrequent tasks where clarity beats low-level control\n\nIn other words: bytes are a power tool. If you don’t need them, they’ll slow you down. If you do need them, they’ll save you.\n\n## FAQ-style quick answers (things people ask me on teams)\n### “Why can’t I write to ArrayBuffer directly?”\nBecause ArrayBuffer is raw storage. JS forces you to pick a view (Uint8Array, DataView, etc.) so reads/writes always have an interpretation.\n\n### “Should I use Uint8Array everywhere?”\nFor payload bytes, yes—Uint8Array is the default byte view. For structured fields and endianness, I switch to DataView.\n\n### “Is DataView slower?”\nIt can be slower for bulk vector operations, but it’s often irrelevant compared to the cost of I/O and copying. I prioritize correctness first, then optimize hotspots with measurement.\n\n### “How do I avoid copying when slicing?”\nUse a view: new Uint8Array(buffer, offset, len) or .subarray(...). Use buffer.slice(...) only when you want a copy.\n\n### “What’s the safest way to accept input from users?”\nNormalize to a Uint8Array window of the intended bytes, validate minimum sizes and hard maximum sizes, and do bounds checks before every read of variable-sized data.\n\n## Summary cheat sheet (what I’d pin to my monitor)\n- ArrayBuffer is bytes only; views interpret bytes.\n- Uint8Array is the default view for “just bytes.”\n- DataView is for structured parsing and explicit endianness.\n- Always preserve byteOffset/byteLength when normalizing views.\n- slice() copies; windowed views don’t.\n- Transfer to workers to avoid copies; expect detached buffers afterward.\n- Add bounds checks first, then parse; never trust length fields blindly.\n\n## Expansion Strategy\nAdd new sections or deepen existing ones with:\n- Deeper code examples: More complete, real-world implementations\n- Edge cases: What breaks and how to handle it\n- Practical scenarios: When to use vs when NOT to use\n- Performance considerations: Before/after comparisons (use ranges, not exact numbers)\n- Common pitfalls: Mistakes developers make and how to avoid them\n- Alternative approaches: Different ways to solve the same problem\n\n## If Relevant to Topic\n- Modern tooling and AI-assisted workflows (for infrastructure/framework topics)\n- Comparison tables for Traditional vs Modern approaches\n- Production considerations: deployment, monitoring, scaling\n
