Weight Conversion Is Exact Math. So Why Do Apps Round It?

Kilograms and pounds are tied by fixed definitions, not by measurement. So every wrong answer a weight converter gives you is a software choice — not a physics problem.

The definitions do the work

One pound is defined as exactly 0.45359237 kilograms. One stone is defined as exactly 14 pounds. One ounce is exactly 1/16 of a pound. Nothing here is measured, estimated, or calibrated. The whole system hangs off a single exact constant:

const KG_PER_LB = 0.45359237;          // exact, by definition
const LB_PER_KG = 1 / KG_PER_LB;       // 2.2046226218...
const KG_PER_STONE = 14 * KG_PER_LB;   // 6.35029318
const KG_PER_OZ = KG_PER_LB / 16;      // 0.028349523125

That means a weight converter is one of the rare programs where "correct" has a sharp edge. If your tool says 70 kg is 154 lb and then converts 154 lb back to 69.85 kg, the tool is not approximately right. It destroyed information and then reported the damage as a fact.

This is the core design decision, and it has exactly one honest answer: store full precision, round only for display. The converter I built — the Weight Converter on ToolkitLoop — keeps the raw value untouched and lets the user pick how many decimals to see. The rounding happens once, at the edge, for human eyes:

function display(valueKg, toUnit, decimals) {
  const raw = valueKg / UNITS[toUnit];   // full precision, always
  return raw.toFixed(decimals);          // rounding happens here, once
}

Storing "2.2" as the conversion factor is not a simplification. It is a bug that compounds every time a value passes through the tool twice.

Stones, pounds, and ounces stay distinct

A tempting shortcut is to normalize everything to pounds and treat stones as "big pounds". Do not. Stones, pounds, and ounces are distinct units with distinct social contexts: body weight in the UK is "11 stone 4 lb", a recipe is grams and ounces, shipping is kilograms and pounds. A converter that flattens them into one scale will misread compound input — and compound input is how humans actually write weights.

The clean model is a table of exact factors against one base unit, kilograms:

const UNITS = {
  kg: 1,
  g: 0.001,
  lb: 0.45359237,
  oz: 0.028349523125,
  st: 6.35029318,
};

Convert through the base, never unit-to-unit. Add a unit and you add one line. There is no matrix to keep in sync and no pair of units that can quietly disagree.

Parsing what people actually type

Nobody types "7.25 lb". They type "7 lb 4 oz". So the tool's smart input parses compound values directly — the same input box also accepts "10 km to miles" or "5'8" to cm" for its sibling converters, but the weight tool only answers for its own units:

function parseCompound(input) {
  const parts = [...input.matchAll(/([\d.]+)\s*(kg|g|lb|oz|st)\b/gi)];
  let kg = 0;
  for (const [, value, unit] of parts) {
    kg += parseFloat(value) * UNITS[unit.toLowerCase()];
  }
  return kg; // "7 lb 4 oz" -> 3.289 kg, unrounded
}

Two rules keep this honest. Convert each part through the exact factor before summing — never round the parts and then add them. And be strict about unit tokens: unrecognized words must fail loudly, not silently become zero. A parser that guesses is worse than one that asks.

The one conversion that is not exact

Cups to grams. A cup is a volume, a gram is a mass, and the bridge is the ingredient's density — a property of the flour, not of the math. The converter's FAQ says this plainly, and it is the right call: commonly used approximations are 1 cup of all-purpose flour ≈ 120 g, 1 cup of granulated sugar ≈ 200 g, and 1 cup of butter ≈ 227 g, but those are averages, not definitions.

If your tool offers cups, label the density, let the user change it, and mark the result approximate. A converter that quietly bakes in one density and presents the result as exact is not being helpful — it is laundering a guess into a fact. Honest imprecision beats confident error.

The numbers that matter

For reference, the pairs people actually look up, all from the fixed definitions above:

• 1 kg = 2.20462 lb; 1 lb = 0.45359237 kg
• 1 stone = 14 lb = 6.35029 kg; 11 stone 4 lb = 71.67 kg
• 100 g = 3.53 oz; 250 g = 8.82 oz; 500 g = 17.64 oz
• 45 lb (a standard gym plate) = 20.41 kg — not 20 kg

None of these needs a server. The converter runs entirely in the browser: free, no sign-up, nothing uploaded. Weight numbers are often health data or business data, and a tool with no backend has nothing to leak because there is nothing to send.

So here is the question I would put to any converter author: does your tool round its stored value, or only its display? If it rounds the stored value, you have built a machine that loses weight every time it is used — and your users will find out from their recipes before they find out from your changelog.

Disclosure: I built the Weight Converter as part of ToolkitLoop, a set of free tools that run entirely in your browser.