Where the numbers come from

Every unit is defined against one base unit

The 22 unit converters do not store conversions between pairs of units. They store 183 numbers: for each unit, what one of it is worth in that dimension's base unit. Length is based on the metre, mass on the kilogram, pressure on the pascal, data on the byte, and so on. A conversion is then two steps, into the base unit and then out of it, which is why 1540 ordered unit pairs need 183 stored values rather than 1540 of them.

That is not a space optimisation. A pairwise table has to be kept internally consistent by hand, and the failure mode is that two routes between the same units disagree. Going through a base unit makes that impossible: there is only ever one route.

// src/tools/units/dimensions.ts
export function toBase(unit: UnitDef, value: number): number {
  if (unit.reciprocal !== undefined) return unit.reciprocal / value;
  return value * (unit.factor ?? 1) + (unit.offset ?? 0);
}

export function fromBase(unit: UnitDef, base: number): number {
  if (unit.reciprocal !== undefined) return unit.reciprocal / base;
  return (base - (unit.offset ?? 0)) / (unit.factor ?? 1);
}

export function convert(from: UnitDef, to: UnitDef, value: number): number {
  return fromBase(to, toBase(from, value));
}

That is the whole conversion engine. Three forms are supported, in this order of precedence. Reciprocal units divide instead of multiplying, which is used by the 4 fuel economy units where miles per gallon and litres per 100 km are inverses of each other. Affine units apply a scale and an offset, used by the 12 units whose scale does not share a zero with the base: Fahrenheit, Kelvin, Rankine, Réaumur, and the shoe and clothing scales. Linear units, which is everything else, are a single multiplication.

Exact definitions where an exact definition exists

Where a unit has a defined value rather than a measured one, the defined value is stored in full. The inch is exactly 0.0254 m and the mile exactly 1609.344 m by the 1959 international yard and pound agreement, so metric to imperial length is exact rather than approximate. The pound is exactly 0.45359237 kg. An acre is exactly 4046.8564224 m². Standard atmosphere is exactly 101,325 Pa. The nautical mile is exactly 1852 m, and a knot is one of those per hour.

Data storage keeps the decimal and binary prefixes separate rather than picking a side: a kilobyte is 1000 bytes and a kibibyte is 1024, both are offered, and they are grouped under those names in the interface. That is the distinction IEC 80000-13 defines, and it is why a drive sold as 1 TB is reported by Windows as 931 GB.

Where the numbers are approximations, and why

Some quantities have no exact definition to derive from. Those are approximations, they are marked as such in the interface, and pretending otherwise on this page would defeat its purpose.

Everything is computed in double precision

There is no arbitrary-precision arithmetic anywhere in the converters. Every value is a JavaScript number, which is an IEEE 754 binary64 double: about 15 to 17 significant decimal digits. For unit conversion that is far more headroom than any physical measurement carries, but it does have visible edges, and the honest thing is to name them.

Converting 100 °C to Fahrenheit produces 211.99999999999997, not 212. That is binary64 doing exactly what it is specified to do: 5/9 has no finite binary representation, so the round trip through the base unit lands one unit in the last place short. The tool shows 212 in the headline and the unrounded 211.99999999999997 in a field labelled Exact result, so the rounding is visible rather than hidden.

Two consequences worth knowing. A conversion is not always its own inverse at the last digit, so converting out and back can move the final digit. And chaining conversions accumulates that, which is one more reason everything routes through a base unit exactly once instead of hopping between units.

How results are rounded for display

The significant-figures control on each converter runs from 1 to 15 and defaults to 6, with five dimensions overriding that default: temperature and fuel economy to 4, angle to 8, shoe and clothing sizes to 3. Those defaults reflect how precise the underlying numbers actually are, not how precise they could be printed.

The formatter is deliberately more generous than the control suggests, and this is the one place where the label and the behaviour differ. It rounds to four more significant figures than requested, then prints up to ten decimal places, falling back to exponential notation below 1e-6 or at or above 1e15. So asking for 6 significant figures on one third returns 0.3333333333, not 0.333333. The control is a floor on displayed precision rather than an exact digit count, and it saturates near ten decimal places.

What each converter page shows about its own arithmetic

• The formula in the direction you asked for, written out with the actual factor, or for an affine pair the factor and the offset.
• The reverse conversion, computed rather than assumed.
• The stored base-unit value for both units, printed to twelve significant figures, so the factor the tool used is inspectable.
• The unrounded result of the conversion you ran.
• A quick-reference table of common values, and every other unit in the dimension converted from the same input.

Converter pair pages under /convert also emit a machine-readable Dataset describing the conversion, including the factor as a PropertyValue and a measurementTechnique that states which of the three forms was used. That is the same number the page displays, read from the same data.

The citation policy, and how far it currently reaches

A tool can carry a references list naming the specifications it implements. When it does, those are rendered on the page as a cited sources block and emitted as schema.org citation. They are followed links, not nofollow ones, because citing a source you are unwilling to link to is not citing it.

The honest state of that policy today: 73 of 624 tools carry references, 189 citations in total across 128 distinct sources, every one of them naming a publisher. Coverage is thickest where a tool implements a written specification rather than a convention, which is why the most-cited publishers are IETF (50), Microsoft (23), W3C (22), arXiv (13).

Two things follow from a number that low. A tool with no references is not thereby unsourced, because most of them implement something with no specification to cite, such as a percentage or a text transform. But the tools that do implement a specification and still cite nothing are a real gap, and the next one below is the largest.

Corrections

If a factor here is wrong, it is wrong in one place and one edit fixes it everywhere it is used: the tool, the pair pages, the formula, the structured data and the worked examples all read the same value. Send the unit, the value you expect and the source that defines it to hello@convertto.tech.