Float16Array: When Half-Precision Saves Memory

A million-element Float64Array costs 8MB. The same million numbers in a Float16Array cost 2MB, a quarter of the memory, for giving up precision most workloads never used in the first place. That’s the entire pitch for half-precision floats, and as of Chrome 135, Firefox 129, and Safari 18.2, it’s a native, standardized part of JavaScript rather than something you’d reach for a library to fake.

What it actually is

Float16Array is a typed array backed by IEEE 754 half-precision floating point numbers, 2 bytes per element instead of 4 (Float32Array) or 8 (a normal JavaScript number, which is a 64-bit double under the hood). The TC39 proposal reached Stage 4 in February 2025 and landed in all three major engines within months, reaching Baseline status in April 2025.

const weights32 = new Float32Array(1_000_000); // 4,000,000 bytes
const weights16 = new Float16Array(1_000_000); // 2,000,000 bytes

weights16[0] = 0.7315;
console.log(weights16[0]); // 0.7314453125 (rounded to float16 precision)

The language also ships Math.f16round(), the float16 counterpart to the existing Math.fround(), which rounds a regular number to the nearest value representable in float16. It’s useful when you need to know ahead of time how a value will get truncated before it lands in the array.

Math.f16round(0.1 + 0.2); // rounds the float64 result to float16 precision

The precision you’re trading away

Half-precision float gives you roughly 3-4 significant decimal digits and a maximum finite magnitude around 65,504, against roughly 7 digits and a vastly larger range for float32. Two concrete failure modes worth knowing before you reach for it:

	Float64 (JS default)	Float32	Float16
Bytes per element	8	4	2
Significant decimal digits	~15-17	~7	~3-4
Max finite magnitude	~1.8 × 10³⁰⁸	~3.4 × 10³⁸	65,504
Typical use	General application data	GPU/graphics, ML inference	Quantized ML, normalized GPU buffers

Store 100000 in a Float16Array and it overflows to Infinity, not a rounded approximation. Store a value like 123.456 and it gets rounded to whatever the nearest representable float16 value is, silently. Neither of those is a bug in the implementation; it’s the format doing exactly what half-precision floats do. The mistake is using Float16Array somewhere that assumed full precision was free.

Where it’s the right tool

The use cases that justify float16 all share one property: the workload was already tolerating reduced precision, or was going to convert to a low-precision format regardless.

Quantized ML model weights and activations. Machine learning models increasingly ship and run in reduced precision, float16 or the related bfloat16 format, specifically because neural network weights don’t need 7 digits of accuracy to produce correct predictions, and the memory savings let larger models fit in the same amount of RAM or VRAM. A JavaScript-based inference pipeline moving weights around benefits from Float16Array the same way the underlying model formats already do.

GPU compute and graphics buffers. WebGPU and WebGL both commonly use half-precision buffers for texture data, vertex attributes, and compute shader inputs, since GPU memory bandwidth is frequently the actual bottleneck, not arithmetic precision. Building those buffers from a Float16Array on the JavaScript side avoids an extra conversion step and halves the data transferred to the GPU compared to sourcing from Float32Array.

Large normalized datasets. Data that’s already scaled to a bounded range, 0 to 1, -1 to 1, a fixed percentage, doesn’t need float32’s extra range or precision. A million-point normalized dataset held in memory for client-side visualization or analysis is a reasonable candidate, provided you’ve checked that 3-4 significant digits doesn’t lose information that matters for your specific values.

Where it isn’t

For ordinary application data, financial figures, geographic coordinates, IDs, anything where a silent rounding error is a correctness bug rather than an acceptable approximation, Float16Array is the wrong tool regardless of the memory savings. It’s also not generally a speed optimization for CPU-bound arithmetic: JavaScript engines typically convert float16 values to float32 or float64 internally to perform math on them, so the benefit is memory footprint and transfer bandwidth, not computation throughput. If your bottleneck is CPU-bound math rather than memory or bandwidth, Float16Array won’t fix it and may add a false sense of having optimized something.

The same reasoning that applies to picking a database primary key strategy applies here: match the format to the actual constraint you’re solving for. If the constraint is memory or transfer bandwidth on data that already tolerates reduced precision, Float16Array is a real, standardized, Baseline-supported answer. If it isn’t, the 2-byte savings aren’t worth the precision hazard.