File, Blob, and ArrayBuffer often appear in the same browser workflow, but they solve different problems: File describes selected input, Blob packages immutable bytes with a media type, and ArrayBuffer exposes raw memory to parsers and codecs.
Keeping those roles separate avoids accidental Base64 inflation, repeated copies, incorrect MIME types, and large memory spikes when processing archives, images, PDFs, or audio.
The short comparison
File extends Blob, adding name, lastModified, and optional relative-path metadata. ArrayBuffer is a fixed-length byte region without filename or MIME type. Uint8Array and DataView are interpretations over that memory.
| Type | Carries | Typical role |
|---|---|---|
| File | Blob bytes plus source metadata | User-selected input |
| Blob | Immutable bytes plus MIME type | Output, preview, download |
| ArrayBuffer | Raw fixed-length memory | Parser or codec input |
| Uint8Array | Byte view over a buffer | Read or modify bytes |
| ReadableStream | Chunks over time | Incremental processing |
File is an input contract, not a disk handle
A File is a browser-managed snapshot of content the user explicitly selected through a picker, drag-and-drop, clipboard event, or granted file-system handle. It does not let a page browse arbitrary local paths.
Methods such as arrayBuffer(), text(), stream(), and slice() read the selected content. Reading is local; upload occurs only if application code deliberately places the value in fetch, XMLHttpRequest, WebSocket, or another outbound channel.
Blob packages a binary result
Blob is useful when output needs a type such as image/webp, application/pdf, or application/zip. It can be sliced, passed to createImageBitmap, used as a request body, exposed through a Blob URL, or saved with a download link.
Blob is immutable. A transform normally follows Blob to ArrayBuffer, then typed-array or library work, then a new Blob. Input and output remain distinct values.
const file = input.files![0];
const bytes = new Uint8Array(await file.arrayBuffer());
const output = new Blob([bytes], { type: 'application/octet-stream' });ArrayBuffer exposes bytes
ArrayBuffer owns memory but does not define its interpretation. Uint8Array reads unsigned bytes, DataView reads multi-byte integers with explicit endianness, and other typed arrays use other element types.
ZIP libraries, Web Crypto, codecs, and binary parsers accept buffers or typed arrays because they need exact bytes. A view can avoid copying, while slice, concatenation, and cloning without transfer may allocate again.
Conversions have memory costs
await blob.arrayBuffer() materializes the complete Blob. TextEncoder converts strings to UTF-8 bytes and TextDecoder reverses that operation. Base64 is a text representation and is usually the wrong internal format.
A large workflow may simultaneously retain the File, an ArrayBuffer, decoded pixels, and output Blob. Use slicing or streams when possible, transfer buffers to workers, revoke stale Blob URLs, and release old previews.
- Use File at the input boundary.
- Use Blob for binary output and download.
- Use ArrayBuffer or typed arrays inside parsers.
- Use streams for incremental formats.
- Use Base64 only when a text-only interface requires it.
ToolGarden example
ZIP tools read File objects into Uint8Array, pass entries to fflate, and wrap returned bytes in an application/zip Blob. Image tools decode a File, transform pixels, and receive a new Blob from Canvas or a codec.
These types do not guarantee privacy by themselves. Privacy comes from keeping them out of outbound requests.
Key takeaways
Use File for selected input, ArrayBuffer and typed arrays for byte work, Blob for output, and a Blob URL for temporary browser access. This staged model is clearer and more efficient than converting everything to strings.