Getting Metric or Imperial Units Right in AI Output by Locale
9 min read · updated August 11, 2026
The output is not wrong in any way a test can see. It says the oven should be at 180 degrees, the counter is 91 cm high, and the drive is 400 km. Every number is correct. For a reader in Ohio, every number is also useless.
What actually goes wrong
A model trained mostly on English-language text has seen both systems, and it picks between them from context. Where the prompt gives it a strong signal — a US street address, an ingredient measured in cups, the word “Fahrenheit” anywhere nearby — it usually gets it right. Where the prompt is neutral, it falls back on whatever the surrounding phrasing most resembles in training data, and for technical and instructional prose that is very often metric.
The failure is quiet because the output is internally consistent. There is no unit mismatch to catch, no exception, no schema violation. If you are generating product descriptions, recipes, safety instructions, shipping copy or fitness content, the first signal is a support ticket. The second failure mode is worse: a model that converts helpfully but silently, so the same generated paragraph contains one measurement the author supplied and one the model converted, with no marker for which is which.
Which readers are not metric
The set is small and it is worth naming precisely, because “the US and everyone else” is close but not right.
- United States. Everyday and commercial use is US customary — inches, feet, pounds, Fahrenheit, US fluid ounces. SI is legal and is the standard in science, medicine and the military, and the US National Institute of Standards and Technology publishes the official US definitions in its Special Publication 811 (NIST SP 811), but consumer-facing text is customary.
- Liberia and Myanmar. The two other countries routinely listed as not having adopted SI as the primary system for general use. Both have long-running metrication efforts, so treat this as a statement about what a reader is used to seeing rather than about what is legally mandated.
- The United Kingdom, which is the case people forget. The UK is metric for trade and packaging but imperial on the road: distances and speed limits are in miles and miles per hour, draught beer is sold in pints, and body weight is commonly given in stones and pounds. A generated UK driving direction in kilometres is wrong even though the UK is a metric country.
- Canada. Officially metric, but construction lumber, oven temperatures, body weight and height are frequently spoken in imperial. Copy that reads as robotically metric reads as translated.
The factors are exact, and that matters
Most of the conversions people write from memory are rounded. The real ones are exact definitions, fixed by the 1959 international yard and pound agreement and published by NIST, and using the exact value costs nothing:
1 in = 25.4 mm (exact) 1 ft = 0.3048 m (exact) 1 yd = 0.9144 m (exact) 1 mi = 1609.344 m (exact) 1 lb = 0.45359237 kg (exact) 1 oz = 28.349523125 g (exact) degF = degC * 9/5 + 32 degC = (degF - 32) * 5/9
Worked, for a labelled measurement. A worktop at 91.44 cm is exactly 36 inches, which is why kitchen counters in metric countries are so often 91 cm: the standard came from the imperial figure. Going the other way, a person of 180 cm is 180 / 2.54 = 70.866 in, which is 5 ft 10.87 in, which a human writes as 5′11″. An oven at 180 °C is 180 × 9/5 + 32 = 356 °F, and no domestic oven has a 356 setting — the answer a cookbook prints is 350 °F. A 100 km/h limit is 100 / 1.609344 = 62.137 mph, and the sign on the road says 60.
One name, two values
The trap that produces the largest errors is not metric-versus-imperial at all. It is that US customary and British imperial share unit names for different quantities. The UK imperial gallon is defined as 4.54609 litres exactly; the US liquid gallon is 3.785411784 litres exactly. An imperial gallon is about 20% larger.
1 US gal = 3.785411784 L 1 imp gal = 4.54609 L 1 US pint = 473.176473 mL 1 imp pint = 568.26125 mL 1 US fl oz = 29.5735295625 mL 1 imp fl oz = 28.4130625 mL US pint = 16 US fl oz imp pint = 20 imp fl oz
Note the inversion, which is where careless conversion code goes wrong: the imperial fluid ounce is smaller than the US one, while the imperial pint is larger, because a pint is sixteen ounces in one system and twenty in the other. A recipe converted with a single “fl oz” factor and a single “pint” factor drawn from different sources will be internally inconsistent.
The same problem exists for mass at the top end: a short ton is 2,000 lb (907.18474 kg), a long ton is 2,240 lb (1016.0469088 kg), and a tonne is 1,000 kg. Three different things, and in running prose all three are written “ton”.
Rounding is part of the conversion
A converted measurement that keeps its source precision announces itself as a conversion. “Preheat to 356 °F”, “drive for 62.14 miles” and “a 25.4 mm bolt” are all arithmetically correct and all obviously machine-produced.
The rule that matches human writing is to preserve significant figures, not decimal places, and then snap to the granularity the domain actually uses. Oven temperatures snap to 25 °F. Road distances under a mile go to a quarter. Body height goes to the whole inch. Bolt sizes do not convert at all — a 25.4 mm bolt is a 1-inch bolt and the two are different products. That last case is the one to watch: for engineered parts, the correct behaviour is not conversion but substitution of the nearest real part, and a model has no way to know which regime it is in unless the prompt says.
Making the model commit to a system
Three things fix this, in decreasing order of reliability.
- Take the conversion out of the model. Have it emit a magnitude and a unit as structured fields, then convert and format with code using the exact factors above. This is the only approach where the arithmetic is guaranteed. It is also the only one where you can round to a domain-specific granularity.
- State the system and the audience in the system prompt. Not “use imperial” but “the reader is in the United States; use US customary units, and use US fluid ounces and US pints, not imperial”. The second clause matters because the model has seen both and the word “imperial” alone is ambiguous for volume.
- Ask for both, once. For content that crosses markets, “180 °C (350 °F)” is what cookbooks actually print and it removes the decision entirely. It costs a few tokens per measurement and it is immune to the model guessing wrong.
If you are generating at volume, the cheap regression test is a post-processing pass that scans the output for unit tokens and fails the batch if it finds any from the wrong system. It is a short regular expression over cm|km|kg|°C|ml|litre and its customary counterpart, and it catches the case where a long generation starts in the right system and drifts halfway through — which is common, because nothing in the decoding process holds the unit choice fixed across a thousand tokens.
The neighbouring decisions have the same shape and are worth setting at the same time as this one: whether the decimal separator is a comma or a point, and whether a date is day-first or month-first. All three are set by the same audience fact and all three fail silently.