How we build accurate converters

Where our unit conversion factors come from

Length, weight, volume, area, and speed factors follow the International System of Units (SI) and, where relevant, US customary definitions published by national metrology bodies. Some are exact by international agreement rather than measured: 1 inch = 2.54 cm exactly, 1 pound (avoirdupois) = 0.45359237 kg exactly, and 1 international nautical mile = 1,852 m exactly. Others are derived to full precision from those exact definitions, such as 1 US liquid gallon = 3.785411784 liters and 1 mile = 1.609344 km. We treat definitions of this kind the way a metrology reference (in spirit similar to a NIST handbook of weights and measures) would: as fixed constants, not approximations, even though on-page results are rounded for readability.

Temperature is handled separately because Celsius, Fahrenheit, and Kelvin do not share a common zero point, so a single multiplier cannot convert between them. We use the standard affine formulas — °F = (°C × 9/5) + 32, °C = (°F − 32) × 5/9, and K = °C + 273.15 — rather than mental shortcuts like "double and add 30," which introduce visible error at higher temperatures (for example, at 200°C the shortcut is off by roughly 8 degrees Fahrenheit).

Volume units get particular attention because "gallon," "cup," and "fluid ounce" are ambiguous words. A US liquid gallon (3.785411784 L) is not the same as a UK imperial gallon (4.54609 L) — about a 20% difference — and a US legal cup (240 mL, used on US nutrition labels) differs from the traditional US customary cup (≈236.588 mL) and from a metric cup (250 mL) used in Australia and some other countries. Every volume converter page states explicitly which definition it uses so you are not silently given the wrong figure for your recipe, fuel receipt, or import paperwork.

Calculation precision and rounding

Calculations on /convert/* pages run in your browser using standard double-precision floating-point arithmetic, applying the full, non-rounded conversion factor to your input. Only the displayed result is rounded — typically to a sensible number of significant digits for the unit in question — so that intermediate rounding never compounds into a materially wrong on-screen answer. Automated tests cover representative conversion pairs across every category (length, weight, temperature, volume, area, speed) so a code change cannot silently break a formula without a test failing first; see convert.test.ts in our codebase for the specific cases we assert against.

How we write and prioritize pages

Guides on /guides/ are researched and written in plain language — metric vs imperial, cooking cups, temperature scales, area and land measurement, PDF workflows, and converter safety. Each converter page includes a direction-specific introduction, a worked numeric example, a conversion table for common values, and an FAQ addressing the mistakes people actually make with that pair. We do not publish duplicate doorway pages that only swap a unit name into an identical template with no added context; the intro, example, and FAQ copy are written per pair or per category, not generated from a single fill-in-the-blank string.

Across six categories there are hundreds of mathematically possible unit pairs. Many of those combinations are obscure — nobody benefits from a near-empty page that only swaps unit names into an identical template. We publish dedicated pages only for everyday pairs where we have written unique use cases, tips, and FAQs. Every other combination is available through the interactive hub converter on each category page (pick any two units; math still runs in your browser). Old thin URLs permanently redirect to the relevant category hub so we never leave reviewers or readers on a low-value duplicate page.

PDF and Word conversion engines

Word→PDF uses LibreOffice running headless on our conversion server — the same rendering engine underlying many enterprise and government document pipelines — chosen because it reproduces complex formatting (multi-column layouts, embedded tables, styles, footnotes) far more faithfully than lightweight browser "print to PDF" or HTML-based exporters. PDF→Word uses pdf2docx, a Python library that parses PDF page structure (text blocks, table boundaries, image positions) and reconstructs it as an editable DOCX file. Both tools have real limitations worth stating plainly: pdf2docx cannot recover text from a scanned PDF, because a scan is a picture, not text — optical character recognition (OCR) would be required first, and we do not currently perform OCR. Heavily designed layouts (magazines, forms with checkboxes, dense multi-column newsletters) may need minor manual cleanup after conversion in either direction. We consider 90–95% layout fidelity a realistic expectation for typical business and academic documents, not a guarantee of pixel-perfect output.

Files are processed in isolated, temporary storage on the conversion server and deleted as soon as your download begins. We do not index, retain, or use uploaded documents for any purpose, including model training. See our Privacy Policy for full detail on retention and data handling.

Testing and quality checks

Beyond the automated conversion-factor tests mentioned above, we periodically spot-check converter pages against independent calculators and reference tables, review new guide drafts for factual accuracy before publishing, and check that FAQ answers stay consistent with the formulas shown on the same page. When a reader points out a discrepancy, we treat it as a real bug report, not noise — see corrections below.

Corrections process

Found an error — a wrong factor, an outdated screenshot, a broken link, or a guide that no longer matches current tool behavior? Email contact@convert-hub.net or use our contact page with the page URL and what looked wrong. We update factors, copy, and screenshots when standards, unit definitions, or our own tools change, and we would rather issue a quick correction than leave a known error live.