I once shipped a bug caused by 24 bytes. A storage quota check in a Laravel app compared an uploaded file's size against a limit the product team had written as "500 MB." The uploader reported megabytes as MiB. The limit was enforced in decimal MB. The gap between the two is about 4.6%, which is invisible in testing and extremely visible when a customer's 512,000,000-byte export gets rejected as "too large" while the UI insists it is under the limit.
Unit conversion looks like the most boring problem in computing right up until it silently corrupts something. Every conversion has an exact defined factor — one inch is exactly 0.0254 meters, one pound is exactly 0.45359237 kilograms — and the reason we get them wrong is that we carry around rounded approximations instead. So I built the Unit Converter on toolz.dev around the defined values, covering the eleven categories I actually reach for, including the ones most converters ignore: CSS pixels, typographic points, and the binary-versus-decimal data units that caused my bug.
TL;DR: Every unit in a category is a fixed multiple of one base unit, so conversion is a single multiply-and-divide — except temperature, which needs an affine transform because Celsius, Fahrenheit, Kelvin, and Rankine have different zero points. The Unit Converter covers length, weight, temperature, area, volume, speed, time, data, pressure, energy, and angle with exact standard factors, shows your value in every unit at once, and runs entirely in your browser.
How does unit conversion actually work?
Pick one base unit per category. Express every other unit as a ratio to it. Conversion then reduces to one line of arithmetic:
result = value × (fromUnit.ratio / toUnit.ratio)
For length, the base is the meter. A centimeter has a ratio of 0.01, an inch has 0.0254. Converting 30 cm to inches is 30 × 0.01 / 0.0254 = 11.811. That is the entire algorithm, and it has a useful property: because every conversion routes through the base unit, you never chain approximations. Converting miles to nautical miles goes mile → meter → nautical mile in one expression rather than through a lookup table of pairwise factors, each with its own rounding.
The base units in the Unit Converter are the SI ones where they exist: meter, kilogram, second, pascal, joule, radian, square meter, meter per second. Volume uses the liter and data uses the byte, both for readability rather than strict SI purity.
Temperature is the exception that breaks the model, and it is worth understanding why.
Why is temperature different from every other unit?
Because temperature scales are affine, not proportional. Zero centimeters and zero inches are the same length — nothing. But zero Celsius and zero Fahrenheit are not the same temperature, and neither of them is "no temperature at all." The scales have both a different step size and a different origin.
So a temperature conversion needs two operations, not one: shift the origin, then scale. The standard formulas:
- °F = (°C × 9/5) + 32
- °C = (°F − 32) × 5/9
- K = °C + 273.15
- °R = K × 9/5
Internally the converter routes everything through Kelvin, which is the only one of the four with a physically meaningful zero — absolute zero, the point where thermal motion stops. That also gives a free validity check: if a conversion produces a negative Kelvin value, the input was below absolute zero and is not a real temperature. The tool rejects it with an explanation rather than confidently returning nonsense, which is the kind of small honesty that separates a tool you can trust from one you have to double-check.
A quick reference for the numbers people actually look up:
| Celsius | Fahrenheit | Kelvin | What it is |
|---|---|---|---|
| −273.15 °C | −459.67 °F | 0 K | Absolute zero |
| −40 °C | −40 °F | 233.15 K | Where the two scales cross |
| 0 °C | 32 °F | 273.15 K | Water freezes |
| 20 °C | 68 °F | 293.15 K | Room temperature |
| 37 °C | 98.6 °F | 310.15 K | Human body |
| 100 °C | 212 °F | 373.15 K | Water boils at sea level |
The −40 crossover is the one worth memorizing. It is the only point where Celsius and Fahrenheit agree, and it makes a good sanity check on any conversion routine you write.
What is the difference between MB and MiB?
This is the conversion that costs real money and real bug-hunting hours, so it deserves its own section.
A megabyte (MB) is 1,000,000 bytes — a decimal unit, 10⁶. A mebibyte (MiB) is 1,048,576 bytes — a binary unit, 2²⁰. The binary prefixes (kibi, mebi, gibi, tebi) were standardized by the IEC in 1998 precisely to end the ambiguity, and roughly half the industry ignored them.
The result is a mess that everyone has felt:
| Advertised | Actual bytes | What the OS shows | Apparent "loss" |
|---|---|---|---|
| 1 kB | 1,000 | 0.98 KiB | 2.4% |
| 1 MB | 1,000,000 | 0.95 MiB | 4.6% |
| 1 GB | 1,000,000,000 | 0.93 GiB | 7.4% |
| 1 TB | 1,000,000,000,000 | 0.91 TiB | 9.9% |
Drive manufacturers sell in decimal units, because decimal makes the number bigger. Windows reports in binary units but labels them "GB," which is where the "my 1 TB drive only has 931 GB" complaint comes from — nothing is missing, the label is just wrong. macOS and most Linux tools now report decimal GB honestly. RAM is always binary, because memory addressing is inherently a power of two. Network speeds are decimal and measured in bits, which is a third axis of confusion: a "100 Mbps" connection delivers about 12.5 MB per second, not 100.
The practical rules I follow:
- In code, work in bytes. Convert only at the display layer.
- When you write a limit in a spec, write the byte count in parentheses: "500 MB (500,000,000 bytes)."
- If your API contract says MB, pick decimal, because that is what the label means outside of Windows.
- Never assume the other system agrees with yours. Check.
The Unit Converter lists both families side by side in the Data category, so you can see the gap rather than guess at it. If you are working with raw byte values and want to see them at the bit level, the Binary Translator is the companion tool.
Which conversions do people actually need?
After watching what gets searched and what I reach for myself, the list is short and predictable. Here are the ones worth knowing cold, with the exact factors rather than the approximations:
| Conversion | Exact factor | Quick mental math |
|---|---|---|
| cm → in | ÷ 2.54 | Halve it, then subtract 20% |
| in → cm | × 2.54 | Double it, add 25% |
| km → mi | × 0.621371 | Multiply by 0.6, add a bit |
| mi → km | × 1.609344 | Add 60% |
| kg → lb | × 2.20462262 | Double it, add 10% |
| lb → kg | × 0.45359237 | Halve it, subtract 10% |
| °C → °F | × 1.8 + 32 | Double it, add 30 (rough) |
| km/h → mph | × 0.621371 | Same factor as km → mi |
| L → US gal | ÷ 3.785411784 | Divide by 4, add a bit |
| MB → MiB | ÷ 1.048576 | Subtract about 4.6% |
The mental-math column is deliberately rough — good enough to sanity-check a result, not good enough to ship. The distinction matters: "double it and add 10%" turns 70 kg into 154 lb, which is right to within a gram. But applied to a 2,000 kg shipment it drifts, and applied to a dosage calculation it is unacceptable. Use the heuristic to catch a wrong order of magnitude; use the exact factor for the actual answer.
Are these conversion factors exact or rounded?
Exact, and this is a more interesting fact than it sounds.
Since the International Yard and Pound Agreement of 1959, the imperial units are defined in terms of metric ones. The inch is not measured against the meter; it is declared to be exactly 0.0254 m. The pound is exactly 0.45359237 kg. The US gallon is exactly 3.785411784 L. There is no experimental uncertainty in these numbers — they are definitions, like the fact that there are 60 seconds in a minute.
The same is true across the categories:
- 1 acre = 4046.8564224 m² (exactly)
- 1 psi = 6894.757293168 Pa (exactly, following from the pound and the inch)
- 1 BTU = 1055.05585262 J (the international-table definition)
- 1 kWh = 3,600,000 J (exactly, since a watt is a joule per second)
- 1 nautical mile = 1852 m (exactly, by international agreement in 1929)
A few units genuinely are conventions rather than definitions, and honest tools say so. "Month" is not a fixed quantity — the converter uses 30 days, because you have to pick something, and a "year" of 365 days ignores leap years. Mach depends on air temperature and pressure; the converter uses the sea-level figure of about 343 m/s at 20 °C. If you need precise date arithmetic instead of a nominal factor, use the Date Difference Calculator, which counts actual calendar days rather than multiplying by 30.
The Unit Converter stores the defined values and rounds only the display, to eight significant digits. The arithmetic itself is done at full double precision, so chained conversions do not accumulate visible error.
Can I convert CSS pixels to millimeters?
Yes, and it is one of the conversions I use most as a front-end developer, which is why it is in the Length category alongside the physical units.
The CSS specification defines the reference pixel as 1/96 of an inch. That makes 96 px exactly 25.4 mm, or 1 px ≈ 0.2646 mm. It also means the relationship between px and pt (the typographic point, 1/72 inch) is fixed: 1 pt = 1.333… px, and 12 pt = 16 px, which is why 16px is the default body font size in every browser — it is 12-point text.
The caveat worth stating plainly: this is a reference pixel, not a device pixel. On a high-DPI display, one CSS pixel maps to two or three physical pixels. On a phone, the viewport scaling changes the relationship again. So px → mm is exactly right when you are mapping a print design onto a web layout (an A4 page is 210 mm wide, which is 793.7 CSS px), and it is a useful approximation rather than a physical truth when you are talking about what your eye actually sees on a Retina screen.
If you are building layouts and design tokens, this conversion plus the Color Picker covers most of the translation work between a designer's print-oriented spec and a CSS implementation.
Common use cases
Development and DevOps. File-size limits, storage quotas, cache sizes, bandwidth budgets. The MB/MiB distinction is the one that bites, and it bites in the places where a wrong number silently rejects a valid request instead of throwing an error you would notice.
Front-end and design handoff. px, pt, mm, and inches when a design comes from a print-oriented tool, or when you are producing something that will be both viewed and printed.
Cooking and recipes. US cups, tablespoons, and ounces versus grams and milliliters. Note that the volume conversions here are US customary — the imperial pint and gallon are separate entries because a UK pint is 568 ml while a US pint is 473 ml, a 20% difference that has ruined a lot of cakes.
Travel and everyday life. km to miles, kg to pounds, Celsius to Fahrenheit, liters to gallons. The unglamorous majority of unit-converter traffic, and the reason the tool defaults to a sensible pair per category rather than making you configure it.
Science and engineering. Pressure in psi, bar, and pascals; energy in joules, calories, kWh, and BTU; angles in degrees, radians, and gradians. Anywhere you are moving between an SI paper and an imperial datasheet.
Fitness and nutrition. Kilocalories (the "calorie" on a food label is actually a kilocalorie) to joules, kilograms to pounds and stones, kilometers to miles for pace calculations. If you are converting percentages of a daily target rather than units, the Percentage Calculator is the other half of that workflow.
For a broader look at which browser-based utilities are worth keeping within reach, I collected the ones I use daily in the web developer's toolkit.
Why does a browser-based converter matter?
For a unit converter, the privacy argument is weaker than it is for, say, a PDF tool — nobody is going to compromise you by learning that you converted 30 cm to inches. But two things still make client-side execution the right architecture.
The first is speed. There is no round trip. The result updates on every keystroke because the arithmetic is happening a few microseconds away, not across a network. A server-backed converter that debounces your input and shows a spinner is slower than doing the multiplication in your head.
The second is that it keeps working when nothing else does. Load the page once and it runs offline — on a plane, on a train, in a datacenter with no guest WiFi, in a conference room whose network hates you. Every tool on toolz.dev is built this way on purpose, and the reasoning behind that choice — for the tools where it genuinely does protect you — is laid out in why your data should never leave your browser.
FAQ
How do I convert cm to inches?
Divide the number of centimeters by 2.54, because one inch is defined as exactly 2.54 cm. So 30 cm ÷ 2.54 = 11.811 inches, and 100 cm ÷ 2.54 = 39.37 inches. The relationship is a definition rather than a measurement, fixed by the International Yard and Pound Agreement of 1959, so it is exact rather than approximate.
How do I convert kg to lbs?
Multiply kilograms by 2.20462262, since one pound is defined as exactly 0.45359237 kg. That makes 70 kg equal to 154.32 lb. The mental shortcut — double it and add 10% — gets you within a fraction of a pound and is fine for a sanity check, but use the exact factor for anything that has to be right, such as shipping weights or dosage calculations.
What is the formula to convert Celsius to Fahrenheit?
°F = (°C × 9/5) + 32. So 25 °C is 77 °F and 100 °C is 212 °F. To reverse it: °C = (°F − 32) × 5/9. Temperature needs both a multiplication and an offset because the two scales have different zero points, unlike length or weight where a single multiplier is enough.
What is the difference between MB and MiB?
A megabyte (MB) is 1,000,000 bytes, while a mebibyte (MiB) is 1,048,576 bytes, or 1024². The gap is about 4.6%, and it grows with each step up: a gigabyte and a gibibyte differ by 7.4%. Drive manufacturers advertise in decimal MB and GB, while Windows reports in binary units but labels them GB, which is why a 1 TB drive appears as roughly 931 GB. Nothing is missing — the two systems are simply counting differently.
How many kilometers are in a mile?
One mile is exactly 1.609344 kilometers, so one kilometer is about 0.621371 miles. A 5 km run is 3.107 miles, a 10 km is 6.214 miles, and a marathon at 42.195 km is 26.219 miles. The same 0.621371 factor converts km/h to mph, since both are the same ratio applied to distance per hour.
Are the conversion factors exact or approximate?
They are the exact defined values from the international standards: 1 in = 0.0254 m, 1 lb = 0.45359237 kg, 1 US gal = 3.785411784 L, 1 nautical mile = 1852 m. Only the displayed result is rounded, to eight significant digits, which keeps output readable without introducing error you would ever notice. The few genuinely conventional units — "month" as 30 days, Mach at sea level — are labeled as such.
Can I convert CSS pixels to millimeters?
Yes. The CSS specification defines the reference pixel as 1/96 of an inch, which makes 96 px exactly 25.4 mm. That relationship is what you want when mapping a print design onto a web layout, and it is why 12 pt equals 16 px. Bear in mind it describes the CSS reference pixel, not the physical pixels on a high-DPI screen, where one CSS pixel may cover two or three device pixels.
Is my data sent to a server when I convert units?
No. Every conversion is computed in JavaScript in your browser, which is also why the result updates instantly as you type rather than after a network round trip. Nothing you enter is transmitted, logged, or stored, and once the page has loaded the converter keeps working with no network connection at all.
