How we build and check these tools

Last reviewed: July 28, 2026 · D. Shin

An online tool is worth using only if you can tell what it actually does. This page describes how the tools on this site are specified, implemented, tested and corrected, so you can judge the output rather than trust it blindly.

1. Every tool names the standard it implements

Nearly all of these tools are implementations of something already published and agreed on. Rather than inventing a method, we implement the standard one and say which it is:

Where a convention is genuinely contested — sleep-cycle length is a good example, since the commonly quoted 90 minutes is an average, not a constant — we say so on the page instead of presenting one number as settled fact.

2. Client-side is a design decision, not a shortcut

Every tool runs entirely in your browser. Nothing you type, and no file you open, is uploaded anywhere. For image tools that means the file is decoded and re-encoded through the Canvas API on your own machine; for text and calculation tools it means plain JavaScript in the page.

The privacy benefit is the obvious one, and it is the main reason. But it also makes the tools fast (no round trip), keeps them working on a bad connection, and removes any question of what a server might retain — a question we cannot answer credibly for you, so we designed it away instead. The trade-off is honest: very large files are limited by your device's memory rather than by a server farm.

3. Testing against known answers

Before a tool ships it is checked against values obtained independently — a published worked example, a reference implementation, or a case with an exact known answer. Sunrise times are compared against published almanac values for several latitudes, including high latitudes where the sun may not rise or set at all. Timestamp conversions are checked across DST boundaries and against dates before 1970, where negative epoch values trip up a surprising number of tools. Colour conversions round-trip: convert out and back, and you must land on the value you started from.

Edge cases get explicit attention because that is where tools quietly fail: empty input, zero, negative numbers, extreme values, a leap day, a 1 × 1-pixel image, an animated or CMYK source file.

4. Precision and rounding

Results are shown to a precision the inputs justify. A TDEE figure printed to four decimal places would suggest an accuracy the underlying equation does not have — those equations carry a standard error of roughly ten percent for an individual, and the page says so. Where rounding could matter (currency, timestamps) we state the rule the tool follows.

5. Review dates and corrections

Pages carry the date they were last reviewed, meaning the method and its output were re-checked against the source standard. When a reader reports a wrong result we reproduce it first, then fix and note it. Corrections are credited to the reporter if they want to be named.

If a tool gives you something that looks wrong, please tell us with the tool and the exact inputs. Reader reports are the cheapest and most effective quality control a site like this has.

What these tools are not

They are practical everyday utilities. The health calculators are not medical or nutrition advice, the finance calculator is not investment advice, and none of them should be the sole basis for a decision that matters. Our full disclaimer is in the terms of service.