Lesson 59 of 80

ArrayBuffer and DataView

Q: When would you reach for DataView instead of a typed array to read binary data, and what specifically does it give you that a typed array doesn't?

A strong answer covers: DataView handles mixed field types and unaligned offsets; a typed array assumes one uniform type at a fixed stride; DataView lets you specify endianness explicitly per read/write, rather than inheriting the machine's native byte order; Concrete use case: parsing a binary file header or network protocol with mixed-size fields; Both DataView and typed arrays are views over the same ArrayBuffer and can coexist over the same memory.

Typed arrays assume one uniform type and your machine's native byte order. DataView drops both assumptions — read mixed field types at exact offsets, in whichever byte order the format demands.

15 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on ArrayBuffer and DataView

What interviewers actually ask about this, and what a strong answer has to cover.

When would you reach for DataView instead of a typed array to read binary data, and what specifically does it give you that a typed array doesn't?

A strong answer covers

DataView handles mixed field types and unaligned offsets; a typed array assumes one uniform type at a fixed stride
DataView lets you specify endianness explicitly per read/write, rather than inheriting the machine's native byte order
Concrete use case: parsing a binary file header or network protocol with mixed-size fields
Both DataView and typed arrays are views over the same ArrayBuffer and can coexist over the same memory

Likely follow-ups

What happens if you forget to pass the endianness argument to getUint32, and the format is actually little-endian?
Could you use a DataView and a Uint8Array on the same buffer at the same time? What would that be useful for?
Why doesn't getUint8 take an endianness argument the way getUint32 does?

Practice these with the AI interviewer →

The plain-language idea

A typed array (Uint32Array, Int16Array, and so on) is convenient exactly when your data is uniform — every slot the same numeric type, laid out back to back. Real binary formats are rarely that tidy: a file header might pack a 4-byte magic number, a 2-byte version, and a 1-byte flag, one after another, with no padding to align them to a typed array's fixed stride. And a typed array reads bytes in your machine's native byte order (almost always little-endian on today's hardware) — but network protocols and many file formats are defined in big-endian, so a plain typed array view would silently read the bytes backwards.

DataView solves both problems at once. It wraps an ArrayBuffer and gives you getUint8, getUint16, getUint32, getFloat64, and their set counterparts — each one taking an explicit byte offset as its first argument and an optional littleEndian boolean as its last. Nothing is inferred from stride or platform; you say exactly which bytes, interpreted exactly which way.

See it in a real thing: parsing a mixed-field binary header

Say a file format defines this 11-byte header, specified in big-endian (network byte order) — the common case for anything designed to be read the same way on any machine:

bytes 0-3:  magic number (uint32)
bytes 4-5:  version (uint16)
byte  6:    flags (uint8)
bytes 7-10: payload length (uint32)

function parseHeader(buffer) {
  const view = new DataView(buffer);

  return {
    magic: view.getUint32(0, false),     // false = big-endian
    version: view.getUint16(4, false),
    flags: view.getUint8(6),             // single byte, no endianness to specify
    payloadLength: view.getUint32(7, false),
  };
}

const res = await fetch("/api/file-blob");
const buffer = await res.arrayBuffer();
const header = parseHeader(buffer);

No typed array here could express this directly — the fields don't share a type, and bytes 7-10 doesn't even fall on a 4-byte-aligned boundary a Uint32Array view would require. DataView doesn't care about alignment at all; you name the exact byte offset for each field.

What people usually miss

Watch out

The endianness argument defaults to big-endian, which is the opposite of most machines' native order. Forgetting to pass true when a format is actually little-endian (many are, including most Intel-era file formats) silently reads every multi-byte value backwards — 0x01000000 instead of 1, no error thrown.
DataView and a typed array can share the exact same underlying ArrayBuffer. You can read the same 11 bytes above as a Uint8Array for a fast byte-level checksum, and as a DataView for the structured header fields — both are views over one buffer, not two copies.
getUint8/setUint8 don't take an endianness argument. A single byte has no byte order to get wrong — the argument only exists on the multi-byte getters/setters, and passing one to getUint8 is simply ignored rather than erroring.

The genealogy: the same buffer, a different lens for a messier shape

The typed-arrays lesson covers the general split between an ArrayBuffer's raw bytes and a view that gives them meaning — and even shows DataView briefly for a uniform, aligned case. This lesson is the deeper cut specifically for DataView: what it buys you once the data stops being uniform — mixed field types, no alignment guarantee, and byte order that has to be stated explicitly rather than inherited from the machine you happen to be running on.