Methodology

How a calculator is defined

Each calculator is a single structured definition in the codebase, not a hand-built web page. That definition holds everything specific to it:

• The compute function — the actual implementation of the formula, in TypeScript. This is the calculator. Everything else on the page describes it.
• Input fields with types, units, sensible defaults and valid ranges, so the tool arrives usable rather than empty.
• Output fields with their formats, units and rounding.
• The formula, written out in plain text, so you can check the arithmetic yourself rather than trusting a black box.
• An explanation of what the formula does, why it is the right one, and the mistake people most often make with it.
• Questions and answers specific to that calculation.
• Related calculators, so a dead end leads somewhere useful.

The page template then renders that definition. This is why the site can cover 11 subject areas at this scale, and it is also the honest explanation for why the pages share a structure: the shape is shared, the formula, explanation, worked numbers and questions are not.

Where the numbers on the page come from

When you open a calculator, it already shows a worked result. That is not a sample image or placeholder text: the server runs that calculator’s own compute function against its default inputs and renders the real output. When you change an input, the same function re-runs in your browser. There is one implementation, and both the example and your calculation go through it — so the worked example on the page cannot disagree with the tool on the page.

No sign-up, and your inputs are never sent to us.

How the formulas are checked

Every formula is covered by automated tests that check its output against worked examples.

In practice that means an automated test suite of over 2,500 assertions across 81 test files, which runs before every build. The checks are of four kinds:

• Known-answer tests. A worked example with a figure established independently — from a textbook method, an official worked example, or hand calculation — is asserted against the implementation’s output.
• Boundary tests. Zero, negative and very large inputs, empty strings, and the edges of tax bands and rate tiers, where off-by-one errors live.
• Invariant tests. Properties that must hold whatever the inputs: a loan’s payments must sum to principal plus interest; percentage components must total 100; converting a unit and back must return the original value.
• Catalog integrity tests. Every calculator must have a unique slug, a working compute function, defined inputs and outputs, a non-empty explanation, and a canonical URL matching its route. These catch a broken definition before it becomes a published page.

What this does and does not prove

It proves the implementation computes what we intended, consistently, and that it has not regressed. It does not prove the intention was right for your situation, and it does not catch an error in a rate or threshold that was transcribed incorrectly from the source and then tested against the same incorrect value. That failure mode is real, and reader corrections are how it gets found — which is why the report an error route matters more than any claim on this page.

Who reviews the methodology

Plainly: there is no panel of named expert reviewers, and we are not going to imply one. Verification here is the automated suite described above plus corrections from readers who know a subject better than we do. If a page ever says it was reviewed by a named person, that will be because a real, named person actually reviewed it and agreed to be credited.

Rates, thresholds and country-specific figures

Calculators that depend on published figures — tax bands, minimum wages, contribution limits, registration fees — carry those figures for a stated jurisdiction and period. They are transcribed from the responsible authority’s published tables. Where a page can cite the exact official document, it does; where it cannot, it states the formula in full instead of citing something vague. There are no decorative citations on this site.

Country and state variants exist only where the underlying rule genuinely differs. 200 countries are covered this way. A variant that would be identical to the general version is not published as a separate page, because that is how a catalog turns into noise.

Which pages we allow into search results

Not every page in a catalog this size deserves to be indexed, and pretending otherwise is bad for readers and for us. A calculator page is offered to search engines only if it has substantive explanatory content alongside the tool: a stated method, a worked example, specific questions and answers, stated assumptions, and text that is genuinely different from its sibling pages.

Pages that do not clear that bar are marked noindex and left out of the sitemap. They stay reachable — the tool still works and you can still link to it — they are simply not put forward as search results. Pages are also never deleted to hide them; a weak page gets improved, merged into a better one with a redirect, or de-indexed.

Corrections

When a calculator is found to be wrong it is fixed, and a regression test is added so the same error cannot return. If a page’s figures are out of date beyond usefulness, it is updated or withdrawn rather than left to mislead.

The limits of all of this, by subject area, are set out on the Disclaimer page. The short version belongs here too: Results are estimates for general information, not professional financial, tax, legal or medical advice.