Start with the actual task
A tool should solve a specific job without making the workflow harder to understand. We check that its labels, accepted input, result, and download or copy action describe the same capability.
Our working standard
clevr.tools is built for small tasks that need a clear answer: what this tool does, where processing happens, and what to expect from the result. This page explains the standard we use when we publish, review, update, or pause a tool.
Last reviewed:
How we evaluate
A tool should solve a specific job without making the workflow harder to understand. We check that its labels, accepted input, result, and download or copy action describe the same capability.
Tools that process files or text locally are described that way. A capability that would require external processing stays unavailable until its processor and data-handling terms can be clearly presented before use.
For the behaviors and inputs covered by our current checks, we use focused regression tests and representative fixtures. Where a tool creates a file, the useful question is whether the downloaded result opens and behaves as expected—not just whether a progress message appeared.
Examples and guidance are meant to explain a workflow, not to overstate certainty. Some tools provide estimates or depend on browser and device limits; those boundaries belong in the product experience, not in fine print.
How we test
Every change to the site runs an automated test suite before it can be released, and a failing check stops the release. For calculators and converters, the tests do not ask the calculator to confirm itself. Each expected value is worked out separately in the test from the textbook formula or the official definition of the unit (for example, the exact definition of a US gallon, or the amortization formula solved by repeated bisection), and the calculator's answer has to match it.
A tool shows a “Verified” line only when such tests exist for it. The tests behind each line are listed in the site's code, and a check fails if a page claims verification without tests that exist. Tools without that coverage show no verified line. Tools that score a performance, such as a typing challenge, say instead that their scoring is covered by automated tests.
What a test cannot do: it shows the tool matches the formula and the examples we thought to check. It does not make an estimate into advice, and it does not cover every browser, device or input. Each tool's “How this is calculated” section names its sources, one tested example and its limits.
“Last reviewed” on a tool page is the date of the latest change to that tool's calculation, content or registry entry in our version history. It is not the date the page was built.
Each tool page also asks “Did this help?” The answer, an optional comment of up to 280 characters, and the time are stored without any IP address or other identifier, and are not shown publicly. See the Privacy Policy.
Evidence and limits
A successful check supports a defined behavior on the input it covers. It does not turn a calculator into professional advice, guarantee every browser or file, or remove the need to inspect an important result. We describe tools as utilities and keep unavailable capabilities out of normal discovery while their requirements are still under review.
Local tools process files or text in browser memory and do not send that content to our servers. If a feature would need external processing, we do not present it as a ready-to-use local workflow. Read the Privacy Policy for the current data-handling details.
Updates and corrections
Material changes to this policy will carry a visible update date. If we find that a capability, claim, or handling boundary needs correction, the appropriate response may be to correct the page, narrow the claim, or temporarily remove the capability from normal discovery while it is reviewed.