Math.sumPrecise() reaches Baseline with order-independent float summation

A new built-in for exact summation

JavaScript now has a standard way to add numbers that always returns the same answer regardless of input order. The method, Math.sumPrecise(), reached Baseline (newly available) status in April 2026, according to a write-up on dev.to that cites MDN compatibility data and web.dev's Baseline digest. Support spans Chrome and Edge 147, Firefox 137 and Safari 26.2.

The bug it fixes

Floating-point addition is commutative for two operands, but long chains of additions are not associative: every intermediate result gets rounded to the nearest 64-bit double, and those roundings land differently depending on ordering. The dev.to article demonstrates with a shopping cart whose reduce()-based total reads 48.54 in one order and 48.53999999999999 after sorting by price — the same eight items, a different total.

Worse cases lose values outright. Adding 1e20, 0.1 and -1e20 in that order with a reduce loop yields 0, because 1e20 plus 0.1 rounds straight back to 1e20 and the small term disappears before the negative value arrives. Accumulating a thousand copies of 0.1 drifts to 99.9999999999986, meaning the naive loop is already wrong around the twelfth digit after a thousand additions.

What the method does

Per the TC39 proposal as summarised by dev.to, the specification requires implementations to compute the true mathematical total of all inputs and round to a float only once, when the final result is produced. With no intermediate rounding, ordering cannot affect the outcome:

[1e20, 0.1, -1e20].reduce((a, b) => a + b, 0); // 0 Math.sumPrecise([1e20, 0.1, -1e20]); // 0.1

The function accepts any iterable, not just arrays, so Map values or a generator can feed it directly. Intermediate overflow does not poison the result either: summing 1e308 twice and subtracting it once returns 1e308, whereas a loop hits Infinity halfway through and never recovers. Performance is not a concern in the informal Chromium 152 test reported by dev.to, where a million random numbers summed in roughly 4 ms with Math.sumPrecise() versus about 16 ms with reduce — though that is a single machine, so hot paths deserve their own measurements.

Where it works, and where it does not

Node.js is the notable gap. MDN's compatibility data lists no Node release, and dev.to reports that typeof Math.sumPrecise returns "undefined" on Node 24.11. For server code or older browsers, dev.to recommends feature detection with a reduce() fallback, or the core-js and es-shims polyfills that MDN links to — while noting that the fallback reintroduces the old order-sensitive behaviour.

Sharp edges worth knowing

• It cannot fix 0.1 + 0.2: Math.sumPrecise([0.1, 0.2]) still returns 0.30000000000000004, because the literal 0.1 was never exactly one tenth to begin with. The method removes error from adding, not from storing.
• No type coercion. Strings, null and BigInt all throw TypeError, so values arriving from form inputs, CSV files or dataset attributes need Number() first.
• It takes a single iterable, not spread arguments — Math.sumPrecise(1, 2, 3) throws. According to dev.to, this is a deliberate choice, since spreading a huge list into arguments can overflow the stack.
• The empty sum is -0. It prints as 0 and compares equal, and only Object.is() can tell the difference.
• Infinity and NaN propagate conventionally: Infinity plus 1 stays Infinity, while Infinity plus -Infinity, or any NaN in the input, yields NaN.
• Currency should still be tracked in integer cents or BigInt. sumPrecise makes float sums correct and stable; it does not make floats the right tool for money.

Why it matters

Order-dependent totals are a genuine correctness bug, not a curiosity: sorting a table, shuffling a dataset or shipping a new engine build can silently change a number shown to users or asserted in tests. For the first time the language itself guarantees a stable, correctly rounded sum in every current browser, which makes every reduce((a, b) => a + b, 0) in a codebase worth auditing where exactness matters. The missing Node support and the representation limits mean it is a better default rather than a cure-all — but for analytics, scoring and aggregation code, it eliminates a whole class of heisenbug.