Trust & Transparency
How We Test
A calculator that is wrong looks exactly like a calculator that is right. That is the whole problem, and it is why the checks below run automatically rather than when somebody remembers.
Nothing on this site is published because it looked fine on screen. Every change has to pass the suites below before it can be committed, and the ones marked before release are run by hand ahead of a deploy. Each entry says what it examines and, more usefully, what it is there to catch — because every one of them exists after something went wrong.
-
Calculation correctness
114 worked examples across 42 of 60 calculators
On every change
Last run 30 August 2026 · 114 of 114 passing
Every tested calculator is opened in a real browser, filled in the way a person would fill it in, and the number it produces is compared against the published formula worked independently.
Catches A calculator that returns a wrong figure. Nothing else here looks at the answer — a page can be flawlessly built, correctly cited and completely wrong.
-
Benchmark regression
193 recorded values
On every change
Every figure each tested calculator renders was recorded when it was last agreed, and is compared character for character on every change — not just the headline, but the breakdown, the totals and the wording alongside them.
Catches A number moving when nobody intended it to. Checking a result against a formula proves it was right; this proves it has not quietly become something else since.
-
Page integrity
20 rules
On every change
Titles, descriptions, headings, canonical URLs, internal links, sitemap membership, structured data, the review block, shareable results, the publisher entity, published file hashes, browser-storage disclosure and dated datasets.
Catches Faults that are invisible on screen. A page missing from the sitemap, a canonical pointing at the wrong address or a storage key the privacy policy does not mention all look perfectly fine in a browser.
-
Result panel
7 rules
On every change
The panel that shows how a result was reached must read the controls that are actually active, must not carry its own second copy of the calculation, and must lay out correctly inside its own column.
Catches A panel that explains a different calculation from the one on screen — for instance describing the wrong tax region, or the wrong one of two tabs.
-
Component compliance
19 checks
Before each release
Inputs, badges, result lists, tables and grids are compared against the site's component patterns, at the level of the CSS that renders them.
Catches Tools drifting apart visually until each one behaves slightly differently from the last, and layouts that overflow on a narrow phone.
-
Sources and citations
18 rules
Before each release
Every tool and guide must carry a review block, every source it cites must exist in the registry, and the authority named on the page must be derived from those citations rather than typed.
Catches A page claiming an authority it does not cite, or citing a source that has been removed. The stated source and the printed one cannot disagree, because one is generated from the other.
-
Tool listings
15 assertions
On every change
Every tool must appear in its category hub, the homepage, the all-tools index and the navigation, in exactly one category, with every count agreeing.
Catches The site advertising a number of tools it does not have, or a tool filed under a section it does not belong to and unreachable from the one it does.
-
Generated content parity
5 parity gates
On every change
Anything generated — the footer, the release log, the widget stylesheet, published widget releases and the embed snippets — is re-derived and compared against what is on disk.
Catches A hand edit to generated markup that works until the next regeneration throws it away, and two copies of the same thing quietly diverging.
-
Security headers
9 assertions
On every change
The content security policy and the other protective headers must be defined identically for every host the site can be deployed to, and each must carry a canonical-address redirect.
Catches The site being less locked down on one host than another, with no deploy failing to say so.
-
Code safety scan
6 patterns
On every change
Newly written code is scanned for dynamic code execution, URL values written straight into the page, third-party scripts without an integrity hash, and anything resembling a hardcoded credential.
Catches The common ways a calculator page becomes a way to attack the person using it.
Where the expected answers come from
The calculation tests do not check that a tool agrees with itself. Each worked example is calculated from the published formula, independently of the code, and the derivation is recorded alongside it — the amortisation formula for a mortgage payment, the compound interest equation for a balance, HMRC’s bands and thresholds for take-home pay, the US Navy circumference equation for body fat.
Each test then opens the real page in a real browser, fills in the real fields and reads the number the page actually displays. It never re-runs the site’s own code to decide what the answer should be, because a test that borrows the formula it is checking will confirm any mistake in it perfectly.
Alongside the worked examples, every test also drives the inputs that break calculators — zero, blank, negative, text where a number belongs, a rate of nought per cent, an end date before the start date — and fails if the page responds with a broken value instead of an answer or an honest refusal.
What this does not prove
These checks show that a calculation matches its stated method. They cannot show that the method is the right one for your situation, and they say nothing about figures that depend on your circumstances: a lender’s actual offer, an employer’s payroll treatment, a clinician’s assessment.
Coverage is partial, and given as a fraction rather than rounded up: 42 of 60 calculators have worked examples behind them. The remaining 18 have none, and they are spread across Health & Fitness (9), Date & Time (6) and Words & Games (3). That number moves as tests are written; a tool without worked examples is still covered by every other suite on this page, and still checked by hand against its sources.
Rates and thresholds change. A tool that was correct in one tax year is wrong in the next unless it is updated, which is why every page carries the date its sources were last reviewed and the period it applies to.
If you find one we missed
A result you cannot reproduce is worth reporting even if you are not sure. Send us the page address and the numbers you entered — that is usually enough to turn it into a test case, which is how a fault gets fixed once rather than found repeatedly.
Corrections that change a result are announced on What’s New, not applied quietly. How sources are chosen and reviewed is set out in our Editorial & Calculation Methodology.