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 most tools ship 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.
"Most" is doing real work in that sentence, so it is worth saying what it leaves out. About one English page in six carries no source at all, and those pages fall into two quite different groups.
For one group that is the correct answer rather than an oversight. A page that adds two fractions, solves a triangle, reduces a ratio, multiplies a matrix, counts combinations or converts a number between bases is doing arithmetic that follows from the definitions themselves. There is no defining document to link, only a textbook restating what the page already shows you, and citing one would be decoration standing in for rigour. The same goes for the pure conversions between binary, decimal and hexadecimal, and for the significant-figures and rounding pages, where the rule is the thing being explained.
The other group is a gap, not a policy, and it is the larger of the two. A tile calculator that tells you how much wastage to allow, a paint calculator quoting a spreading rate, a page on capacitor codes, roof pitch, decibels or sourdough hydration: those carry claims that came from somewhere, and somewhere is exactly what the page ought to name. Several dozen of them do not yet. They are being worked through in the order that the size of the claim suggests rather than the size of the traffic. Until one is done, the split to hold in mind is that the arithmetic is tested and the advice around it is not cited, which is a weaker thing than this note originally implied and worth correcting rather than leaving to be discovered.
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 divides by a term that collapses to zero when the rate does, and the numerator collapses with it. Feed it a 0% loan and both halves vanish, and JavaScript does not raise anything — it quietly returns NaN and lets the page render it. 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, and on most pages 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.