A converter is easy to write and easy to get quietly wrong. The failure is rarely dramatic: a rounding applied one step too early, a definition that changed in 1959, a locale that reads 1,5 as fifteen. Nobody notices until someone prices a shipment.
So each tool ships with a reference: the defining document for the unit or the formula, linked at the bottom of the page. Weight and length conversions cite NIST and BIPM. Finance tools cite the CFPB and Freddie Mac, and their arithmetic is unit-tested against the published formulas. The amortisation maths against the standard annuity formula, the tax bands against the figures the IRS prints.
The arithmetic itself lives in plain TypeScript files with no interface attached, and every one has a test file beside it. That separation is the point. A formula that can only be exercised by clicking through a page is a formula nobody checks at the awkward values, because clicking through a page eighty times is nobody’s afternoon.
Boundaries: zero, one, negative, absurd
Every tool is run at zero, at one, at a negative, at a number large enough to lose precision, and at the value where its own formula divides by zero. That last one is not hypothetical. The standard annuity formula for a monthly payment is the balance times the monthly rate, divided by one minus (one plus that rate) raised to minus the number of payments. Feed it a 0% interest rate and the numerator is zero and so is the denominator, and JavaScript hands back NaN rather than raising anything. A 0% loan is an ordinary thing: furniture, cars, employer schemes, so the tool needs a separate branch that simply divides the balance by the number of payments, and the test that catches its absence is one line long.
Division by zero is the general shape of the problem. JavaScript does not throw; it returns Infinity, which then travels through the rest of the calculation and arrives on the page as a currency-formatted ∞. A percentage change measured from zero, a unit price for zero units, a pace over zero distance: each is a question with no answer, and the right behaviour is to say so rather than print a symbol.
At the other end, whole numbers above 9,007,199,254,740,991 stop being exact in JavaScript. That ceiling is unreachable for a tip calculator and entirely reachable for anything converting bytes.
Locales: the comma that eats a decimal
Much of Europe writes one and a half as 1,5. Hand that string to JavaScript’s parseFloat and it returns 1, not an error, not NaN, just 1, with the half discarded silently. Number returns NaN instead, which is at least honest about having failed. A tool that reads its input with the wrong one of those gives a Dutch visitor a confidently wrong answer and no indication that anything happened.
Output is never assembled by hand either. Intl.NumberFormat turns one number into $1,234.56 for a US visitor and € 1.234,56 for a Dutch one, decimal comma, thousands separator and symbol position included. Writing that logic yourself is a day of work to arrive somewhere worse.
The other half of the locale check is the labels rather than the numbers, and that is a layout problem with its own note.
The phone, at 375 pixels
Every tool has to be usable and readable at 375 pixels wide before it counts as finished. Nothing in the layout carries a fixed width, so narrower degrades rather than breaks, but 375 is a bar to clear rather than a target to approach.
The mortgage calculator took the longest, not because the formula is hard but because the amortisation schedule is 360 rows and a phone is 375 pixels wide. A 360-row table on a phone is a pinch-and-drag exercise nobody finishes, so it became twelve records you expand; a year at a time, which happens to be how people read a schedule anyway.
The two checks that are not arithmetic
Anything date- or time-dependent has to resolve in the browser. Tool pages are served from a warmed HTML cache, so a date rendered on the server is not today’s date; it is the date the cache was built, and it stays that way until something invalidates it. An age calculator that renders the current date server-side is wrong for everyone who arrives tomorrow, and it is wrong without looking wrong.
And data that expires is treated as content rather than as code. Tax bands, contribution ceilings and the inflation series live in each tool’s own configuration alongside a source and the date they were last reviewed, so correcting a January change is an edit rather than a deployment. The review date is printed on the page, because a figure with no review date is a figure you cannot judge.
What is not checked
Nobody with a professional qualification reviews any of this. The tax tools follow the published tables and cite them, which is a different claim from a tax professional having checked the answer against your circumstances. No such reviewer is named anywhere on the site, because none exists, and inventing one is the standard trick of this category.
What is here is arithmetic done carefully against sources you can go and read. The kilograms to pounds factor against the 1959 definition, the payment against the annuity formula. That is genuinely useful and it is not advice, and the distance between those two things is worth keeping visible rather than blurring for the sake of a more confident sentence.