We round-tripped 306 unit conversions a million times. Here's the precision you actually lose.

Every unit conversion on the web runs on IEEE 754 double-precision floating point — the same 64-bit number format JavaScript, spreadsheets, and most calculators use. It is accurate to about 15–16 significant digits, but it is not infinitely precise: most decimal fractions cannot be stored exactly in binary. That raises a natural question. If you convert a number from one unit to another and back, do you get the original number? And if you do it again, and again — does the error pile up?

We tested it exhaustively. For all 306core conversion pairs in Convertitive’s catalogue (every category except temperature, which is an offset conversion rather than a pure ratio), we started at the value 1, converted forward and back, and repeated that round trip one million times. Then we measured how far the result had drifted from 1.

Finding 1: 88% of conversions never drift at all

Of the 306 pairs, 270 (88.2%) returned to exactly 1 after a million round trips — bit-for-bit identical, zero error. These are the pairs whose unit-to-unit ratio is exactly representable in binary floating point, so every conversion is perfectly reversible no matter how many times you repeat it.

That is a stronger result than most people expect. The intuition that “floating-point error always accumulates” is simply false for the majority of real conversions.

Finding 2: even the worst case stays accurate to 15 digits

The remaining 36 pairs did drift — but by almost nothing. Here are the worst offenders after a full million round trips:

The single worst pair, miles → inches, drifted by 1.78 × 10⁻¹⁵ — roughly two parts in a quadrillion, after a million round trips. A normal user performs exactly one conversion, where the error is millions of times smaller still and sits far below the 15th significant digit. In practical terms, the result is exact.

Finding 3: which categories are perfectly stable

Drift clusters by category, and the pattern is explained entirely by how the unit definitions factor into binary:

Data and volume are perfectly stable — every pair round-trips losslessly. Data units are powers of two and ten that binary handles cleanly; the volume units in this catalogue share factors that cancel exactly. The categories with the most drift — power and speed — are dominated by definitions like horsepower and knots that pull in irrational-in-binary factors.

Why this happens

Double-precision floating point stores 53 bits of mantissa, giving a machine epsilon of about 2.2 × 10⁻¹⁶ — the smallest relative gap between representable numbers near 1. A conversion multiplies by a ratio of two unit factors. When that ratio is an exact binary fraction (or the forward and reverse factors cancel exactly), the round trip is lossless and drift is zero forever. When the ratio is notexactly representable — as with the inch’s 0.0254 m or the mile’s 1609.344 m — each conversion rounds to the nearest representable value, leaving an error on the order of one epsilon. Over a million round trips those errors take a slow random walk, which is why even the worst case only reaches a few times 10⁻¹⁵.

The practical takeaway

Unit conversion in the browser is, for all intents and purposes, exact. The error is bounded by machine epsilon, it does not meaningfully accumulate in normal use, and it is always far below the precision you would ever display. If you have ever wondered whether chaining conversions through a tool quietly corrupts your numbers — it does not. For the full picture of how Convertitive’s results compare against authoritative reference values, see the converter accuracy study and the conversion methodology.

Methodology

For each ordered pair of core units (A, B) within a category, we computed v ← v × (factorA / factorB) then v ← v × (factorB / factorA), starting from v = 1, repeated 1,000,000 times, and recorded |v − 1|. Factors are the exact factorToBase values from Convertitive’s unit data, derived from NIST SP 811. All arithmetic is IEEE 754 binary64 (JavaScript’s native number type). Temperature was excluded because it is an affine conversion (it has an additive offset), not a pure ratio, so the round-trip model above does not apply. The procedure is deterministic: the same inputs always produce the same drift values reported here.