How we build and verify a tool
What is checked before a page goes live, how the checks are built, and what they do not cover.
Written and maintained by pengchun.
Why this page exists
Most tool sites ask you to trust the number that appears on screen. There is usually no way to tell whether a calculator was checked at all, or whether its guide was copied from somewhere else and never read. This page is the answer to that: the exact process behind every page here, including the parts that are limited.
The short version: a tool is not published until its answers have been recomputed by a second, independent implementation, its page has been measured in a real browser, and the files on the server have been compared byte for byte with the files that were checked. The longer version is below.
What every tool page contains
Every tool here is a single HTML file. There is no build step, no framework, no bundled dependency, and nothing that runs on a server, which is also why each one loads in well under a second and keeps working offline.
- The tool itself, running in your browser. If a tool needs to compute something, it computes it locally, including the ones that generate images or process long documents.
- A guide to the subject, not a set of instructions for the buttons. It has to explain the rule or formula being applied, where the numbers come from, the edge cases that trip people up, and at least one honest answer about when the tool is the wrong choice. Guides run from roughly 700 to more than 2,000 words.
- At least one reference table that you could still use if the tool disappeared: dates, offsets, limits, benchmarks, worked examples.
- Questions and answers that also appear as structured data, worded identically in both places, because structured data that disagrees with the page is worse than none.
How a number gets checked
The rule that shapes everything else: never check a calculation against itself. If the same code that produces an answer is the code that decides whether the answer is right, the check only proves the code is consistent, not that it is correct. So where a page computes something, the check computes it again from a different direction.
Concrete examples from this site:
- Clock changes. The daylight saving page works out each transition from the written rule, taking the second Sunday in March or the last Sunday in October and converting that wall-clock time to a UTC instant. The check derives the same instants from the IANA time zone database by sampling each zone's offset every six hours and narrowing down to the minute, then requires the two to agree to the millisecond for every listed region in two separate years. A government publication is used as a third opinion where one exists.
- Randomness with a known shape. The generators are checked against the structure they promise, not against their own output: a lottery-style generator has to return the documented count of distinct values inside the documented range, and a UUID tool has to produce values whose variant and version bits match the specification. Repeating the same call and comparing it with itself would prove nothing.
- Checksums and encodings. Claimed digests are recomputed with the platform's own cryptography library rather than the page's code, and round trips are required to reproduce the original bytes exactly, including padded and unpadded forms.
- Statistics. The playoff probability tool is checked against a second simulation built on a different random number generator, a different sampling method and an independently written schedule, with invariants pinned on top: every team lands in exactly one standing bucket, the number of qualifying places equals the number of simulated seasons times the places available, and a team's odds can never improve when it is given a worse result.
The suites that run on every change
More than 4,000 individual checks across 21 suites run before publishing and again on every later change. A suite is either a set of computations, or a real browser.
| Suite | What it covers | Runs in |
|---|---|---|
| validate | The site's own bookkeeping: every page listed, dated and linked consistently, no stray characters, nothing advertised that is not there | Node |
| calc-scoring | The fantasy scoring formula, lifted out of the published page and recomputed | Node |
| subnet-claims | Subnet arithmetic, and the guide and the tool agreeing on it | Node |
| faab-scoring | Bid suggestions: budget limits, minimum bids, tie-breaking | Node |
| live-calc | The published fantasy calculator, driven end to end | Node |
| fantasy-cluster | That the fantasy tools really do link to each other, with a negative control | Node |
| diff-engine | The text diff engine against a second implementation, including line endings and duplicate lines | Node |
| ua-filter | Telling human visits from bots, with regressions for both false kills and leaks | Node |
| browser-diff | The diff tool in a real browser, desktop and phone widths | Chromium |
| favicon-svg | Icon generation: SVG output, size table, data URI round trip, error paths | Node |
| browser-favicon | That the generated icon actually decodes into an image, and the palette really highlights | Chromium |
| playoff-odds | Playoff probability simulation against an independent simulation | Node |
| browser-playoff-odds | Async timing after a click, number inputs, and the clipboard path used by the share button | Chromium |
| coat-of-arms | Shield geometry, charge placement, and blazon text round trips | Node |
| browser-coat-of-arms | The shield rasterised and sampled pixel by pixel, plus palette highlighting | Chromium |
| content-pages | Guide thickness, real tables, and the structured data matching the page word for word | Chromium |
| content-claims | Every specific number stated in a guide, recomputed from the published files | Node |
| mobile-controls | Entry fields large enough that a phone does not zoom, and no page that pans sideways | Chromium |
| daylight-saving | Clock-change instants against the IANA time zone database, region by region | Node |
| browser-daylight-saving | Every region re-rendered on a real change event, with the countdown ticking on its own | Chromium |
| trust-pages | The pages that describe the site itself: the author page, this page, and the About page, including whether the numbers on this page still match the test runner's own record | Chromium |
How we know the checks can fail
A check that can never go red is decoration. It looks like evidence and proves nothing. So each suite ships with a drill that deliberately breaks the thing it is supposed to protect, and the drill fails if the suite does not notice. Across the six drills, 89 deliberate mistakes are made and all 89 are caught.
| Drill | Mistakes made | An example of what it breaks |
|---|---|---|
| Content pages | 10 | Reverts a rewritten guide to the thin four-block skeleton it used to share with 20 other pages |
| Mobile controls | 3 | Shrinks an entry field back to 14 pixels, or deletes the phone-only stylesheet rules |
| Coat of arms | 24 | Draws the crescent with an even-odd subtraction, which leaves a solid cap in the corners |
| Playoff odds | 22 | Swaps the win-out and lose-out bounds, so a team's best case looks like its worst |
| Daylight saving | 21 | Returns the year's first clock change instead of the most recent one |
| Text diff | 9 | Drops the plus-one in the longest-common-subsequence recurrence, shifting alignment |
Where the checks run
Three places, because each one sees something the others cannot.
- In Node, without a browser. Engines are read straight out of the published HTML file and recomputed against a second implementation. This catches arithmetic that is wrong in a way that still looks plausible.
- In a real browser. Layout, computed font sizes, tap targets, focus behaviour, canvas and SVG output, asynchronous timing and the clipboard are measured on a rendered page at a desktop size and at a 390 pixel phone viewport. A DOM stub cannot tell you that a control is 13 pixels tall, or that a page pans sideways on a phone, or that a button did nothing because a promise never settled.
- On the live server, after publishing. Each changed file is compared with the checked local copy by SHA-256, and the origin is re-fetched to confirm the pages still return the expected status, links, and content. A page that passed locally but uploaded wrong is not a hypothetical failure mode; it is why this step exists.
What we do not do
The honest list, because a page about verification that only lists strengths is not a verification page.
- No automated Firefox or Safari matrix. The browser suites run on Chromium. Engine-specific behaviour in Firefox and Safari is checked by hand, which means it is checked less often and less thoroughly than the Chromium path.
- No server-side processing and no accounts. Nothing you paste into a tool is uploaded, stored or logged, so there is no data to retain and no account to lose. That also means there is no server-side record if something goes wrong in your session.
- No third-party feeds for the numbers in the guides. Facts come from primary sources, including RFCs, the IANA time zone database and government publications, and each guide says where its figures come from when it matters. Feeds are convenient and they rot quietly.
- One author, not a review board. Every page here has a single accountable author. That is a real limit: independent recomputation is a strong check on arithmetic and a weak check on judgement.
- No claim that checks make a page useful. A page can pass every suite and still be the wrong tool for your job, so each guide also says when not to use it.
How to check our work yourself
- Turn off your network and reload a tool. Every one of them still works, which tells you the answers are not coming from a server you cannot see.
- Read the guide for the rule, then re-derive a number by hand. If a table gives a limit or a date, the guide should show where it comes from.
- Compare two tools that should agree. Where two pages here describe the same subject, they are checked against each other as well.
- Tell us when something is wrong, through the contact page. The checks on this page grew out of exactly that: real errors that slipped through, each one now pinned by a new check so it cannot come back unnoticed.
Frequently asked questions
Are the tools on this site tested automatically?
Yes. More than 4,000 individual checks run across 21 suites before anything is published, and the suites run again on every later change. Some of those checks read the page's own JavaScript and recompute its answers with a second, independent implementation; others drive a real browser and measure the rendered page.
Do the tools send my data anywhere?
No. Every tool on this site is a single HTML file whose work happens in your browser. There is no upload endpoint and no server-side processing, so you can open a tool, switch off your network, and it still works. The only third-party script on the site is Google Analytics, which counts page views.
How do you know a calculation is correct and not just consistent?
By never checking a calculation against itself. Where a page derives a value one way, the check derives it another way from a different source, and the two have to agree. The daylight saving page, for example, works out clock changes from the written rule, while the check reads the same instants out of the IANA time zone database.
Which browsers are tested automatically?
Chromium browsers: Chrome and Edge in headless mode, at a desktop size and at a real 390 pixel phone viewport. Firefox and Safari are not part of the automated matrix, so anything specific to those engines is checked by hand instead. We would rather say that plainly than claim a test matrix we do not run.
What happens if I find an error?
Tell us through the contact page. Every page on this site has one author who is accountable for it, and a correction is made at the source, republished, and then re-checked by the same suites. When a check fails to catch a real error, a new check for that error is added, which is how most of the checks described here came to exist.