Why Unit Conversion Is Harder Than a Lookup Table in JS

Every developer has thought it at some point: a unit converter is just a lookup table. Store a factor per unit, multiply, done. It is the kind of project that looks like a weekend build and then quietly teaches you three separate lessons about how software actually breaks.

I built the ToolkitLoop Unit Converter (https://toolkitloop.com/unit-converter) as a client-side tool — no ads, no signup, results update as you type, and fixed-unit conversions stay in the browser. It covers common length, weight, volume, temperature, speed, area, and other everyday physical units. Here is where the lookup-table mental model falls apart.

A lookup table assumes one number in, one number out

The tool page suggests typing "10 km to miles", "5′8″ to cm", or "7 lb 4 oz to kg". Notice that two of those three examples are not one number. A height in feet and inches is two numbers in two units. A weight in pounds and ounces is the same.

A converter that only accepts a single value forces the user to do the first conversion themselves — feet to inches, pounds to ounces — before the tool can help. That is the step where mistakes happen, and it is invisible to the tool: it receives a clean single number and returns a confident answer, never knowing the user mangled the input on the way in.

So the input box becomes a parser. It has to recognise compound inputs, decide which tokens are values and which are units, and handle the many ways people write the same thing: 5'8", 5 ft 8 in, 5ft8in. Each accepted form is a test case. Each rejected form is a user staring at an error message for a height they write every day.

The general lesson is one worth remembering beyond converters: the moment an input accepts human phrasing, you own a grammar. Budget for it like a feature, not a detail.

Temperature breaks the multiply-only model

Most unit conversions are ratios. Length, weight, volume: pick a base unit, store one factor per unit, multiply. Temperature refuses to play along. Celsius to Fahrenheit is multiply by 9/5 and then add 32. Fahrenheit to Celsius is subtract 32, then multiply by 5/9. Kelvin is a shift of 273.15 on top of all of it.

// A factor-only table cannot express temperature.
// Carry a scale and an offset per unit; ratios are the
// special case where offset is zero.
function toBase(value, unit) {
  return (value - unit.offset) / unit.scale;
}
function fromBase(base, unit) {
  return base * unit.scale + unit.offset;
}
function convert(value, from, to) {
  return fromBase(toBase(value, from), to);
}

This is a small piece of design with a large blast radius. If the conversion table stores only factors, adding a temperature unit later silently breaks every temperature answer — and the breakage is subtle, because the answers are wrong by a plausible-looking amount, not by an order of magnitude. The fix is to design for the affine case from the start and let ratio conversions fall out as a special case. It costs almost nothing up front and removes a whole class of bug.

It is also a good example of a general rule: when a table looks like it needs one number per row, check whether any row secretly needs two. The second number is usually where the real domain lives.

US vs Imperial: the key is the identity

The converter labels US and Imperial units separately. That label is not decoration — it is the data model showing through the UI.

A US gallon and an Imperial gallon share a name and differ in size. If the internal key for a unit is just its name, the distinction is already lost, and correct arithmetic downstream cannot recover it. The key has to carry the system: gallon_us versus gallon_imperial. And the UI has to show the system, because a user who cannot see which gallon they picked cannot catch the error either.

This pattern — two things with the same display name and different meanings, collapsed into one key — is one of the most common sources of quiet bugs in software. Currency codes, date formats, and locale-specific units all have the same shape. The fix is always the same: make the key carry the distinction, and make the interface show it.

Precision belongs to the user, not the calculation

The converter lets you set precision, and the right number of decimals depends on the task, not the maths. A road trip needs one or two decimals: 10 km is 6.21 miles, and nobody plans a route to four decimal places. A recipe needs whole numbers or one decimal. A measurement for cutting material needs whatever the ruler can actually resolve.

The trap is false precision — printing six decimals for an input that was rounded to one significant figure. The digits look exact, so the user trusts them, but they encode nothing the input did not already contain. The discipline is simple: keep full precision internally, round only when rendering, and let the user choose the display precision.

// Round at the edge, never in the middle of a chain.
function display(value, decimals) {
  const factor = 10 ** decimals;
  return Math.round(value * factor) / factor;
}

Instant results change the architecture

There is no convert button. Results update as you type or change units. That single UX decision shapes the whole implementation: conversion has to run on every keystroke, so it must be cheap, synchronous, and total — it has to produce something sensible for an empty field, a half-typed number, and a unit pair that makes no sense together.

That constraint is what makes the zero-backend design natural rather than forced. Conversion as a pure function of (value, from, to) needs no network, no server, and no account — which is why the tool can be ad-free, signup-free, and entirely client-side. The UX requirement and the architecture are the same decision viewed from two sides.

The open question

If I had to rank the three hard parts — parsing compound inputs, handling affine transforms like temperature, and keeping US vs Imperial labels honest — I would put labelling first. The maths is solved once you carry scale plus offset. The parsing is bounded. But labelling never ends: every new unit system and every same-name-different-size pair is another distinction the interface has to carry without confusing someone who just wants to know how many miles 10 km is.

What has bitten you hardest in a converter, a calculator, or any tool that takes human phrasing as input — the parser, the maths, or the labels? And is there a unit pair you still double-check by hand, no matter what the tool says?

Disclosure: I built this tool. The Unit Converter (https://toolkitloop.com/unit-converter) is part of ToolkitLoop, a set of free browser-side tools that run entirely in your browser — no ads, no signup.