I once watched two people argue over whether a shelf was 3.94 inches or 3.937 inches wide. Both were reading the same 10 cm measurement. One of them was holding a tape measure; the other was holding a calculator with too many decimal places. That argument is why I built a length converter — and why it rounds its answers on purpose.

Disclosure first: I built this tool. The Length Converter at ToolkitLoop is my free browser-side tool, and this post is the build log for it: https://toolkitloop.com/length-converter

Lesson 1: One exact definition anchors everything

Length conversion looks like a table of magic numbers until you find the one definition everything hangs from. Since the international yard and pound agreement of 1959, one inch is defined as exactly 2.54 centimeters. Not measured — defined. That single sentence pins down the foot (exactly 30.48 cm), the yard (exactly 0.9144 m), and every conversion between metric and imperial length.

So the converter does not store a table of factors. It stores one base unit and derives the rest:

// One exact anchor: 1 inch = 2.54 cm, by definition since 1959. const METERS = { mm: 0.001, cm: 0.01, m: 1, km: 1000, in: 0.0254, // exact ft: 0.3048, // exact: 12 * 0.0254 yd: 0.9144, // exact: 36 * 0.0254 mi: 1609.344, // exact: 1760 * 0.9144 }; function convertLength(value, from, to) { return (value * METERS[from]) / METERS[to]; } convertLength(10, "cm", "in"); // 3.937007874015748 convertLength(10, "km", "mi"); // 6.2137119223733395

The raw result of 10 cm is 3.937007874015748 inches. That is mathematically right and practically useless — which brings us to lesson two.

Lesson 2: Round for display, never for the next step

The tool shows 3.94 inches, not 3.937007874015748. That is a deliberate choice, and it is the one I would defend hardest. Rounding the display is honesty: no tape measure resolves the seventh decimal place, and showing fifteen digits pretends at a precision the input never had.

But rounding must happen at the very last moment. If you round to two decimals after every step of a chained calculation, the error compounds — round a dozen boards to the nearest centimeter each and the total can drift by several centimeters. The rule in the code is simple: keep the full float internally, format only when rendering.

// Keep full precision through the math; round only for the eye. function display(value, precision = 2) { const factor = 10 ** precision; return Math.round(value * factor) / factor; } display(convertLength(10, "cm", "in")); // 3.94 — shown convertLength(10, "cm", "in"); // 3.937007874015748 — kept

This is also why the tool exposes a precision control instead of hard-coding two decimals. Cutting fabric wants two; a road trip wants one; machining wants all of them until the final cut.

Lesson 3: Compound input is a parser, not a text field

The most common length input in the real world is not a number — it is a height. People write 5′8″, 5 ft 8 in, or 5 feet 8 inches. And the classic mistake is typing 5.8, which is 5 feet 9.6 inches — a different person.

So the Smart Input is a small parser. It reads a phrase like "10 km to miles" or "5′8″ to cm", splits it into value, from-unit, and to-unit, and handles compound values as two parts that get converted separately and added:

// "5′8″ to cm" -> 5 ft (152.4 cm) + 8 in (20.32 cm) = 172.72 cm function parseHeight(input) { const match = input.match(/(\d+)\s*(?:ft|')\s*(\d+)\s*(?:in|"|″)?/); if (!match) return null; const [, feet, inches] = match; return convertLength(Number(feet), "ft", "cm") + convertLength(Number(inches), "in", "cm"); } parseHeight("5′8″"); // 172.72

The lesson generalizes: whenever users paste real-world notation into your tool, you are building a parser whether you admit it or not. Writing the regex on purpose beats discovering it by accident in your bug reports.

Lesson 4: Precision is a UX choice, not a math choice

Developers love to argue about float precision. Users argue about whether the answer looks right. Both are correct, and they are arguing about different layers.

The converter's precision control exists because the right number of decimals depends on the job, not on the math: two decimals for fabric, whole numbers for furniture, one decimal for a run. There is no single "correct" precision, only a correct default (two decimals) and an honest way to change it. If your tool forces one precision on every use case, it is not being rigorous — it is refusing to decide.

Lesson 5: No backend means no excuses

The whole thing runs in the browser. No account, no upload, no server round-trip. That is partly a privacy decision — a measurement you type should not become a row in somebody's database — and partly an engineering one: conversion is arithmetic, and arithmetic does not need a backend.

It also removes an entire class of excuses. There is no "the server was slow" and no "the API changed the factor." The definitions are fixed, the code is small, and if the answer is wrong, the bug is in the handful of lines above, not in a pipeline.

Try it: https://toolkitloop.com/length-converter — type "10 km to miles" or "5′8″ to cm" and watch the answer update as you type. No convert button, no signup.

The open question

Here is the part I genuinely do not have a settled answer for, and I would like to hear yours: when a converter shows you 3.94 instead of 3.937007874015748, is that honesty or is it hiding information? My take is that rounding for display is honest because the input never had fifteen digits of precision. But I have also heard the opposite argument — that a tool should show everything it knows and let the user decide what to ignore.

Where do you draw the line — and does it move when the use case changes from cutting fabric to machining a part? Drop your rule in the comments. The best answer I have seen so far is "match the precision to the tool you will measure with," and I am curious whether that survives contact with your workflow.

I built this tool — the Length Converter at ToolkitLoop is mine, free, and runs entirely in your browser.