it.you tool methodology: how we verify IT tools
Tool methodology — reviewed October 15, 2026
In short: the it.you tool methodology verifies each IT tool's job, processing boundary, expected output, important limits, and safe way to check the result. A tool is not treated as proof for a security, identity, ownership, or availability decision.
What this methodology covers
Useful output starts with a clear task
This tool methodology applies to the public utilities in the it.you tool directory. Each page should help a visitor complete one named task. Its interface and documentation should agree about accepted input, generated output, and failure cases. We avoid creating separate pages that perform the same job only to target a slightly different phrase.
The method complements our editorial policy. The editorial policy governs articles and learning material; this page explains the checks used for interactive utilities.
Four checks for every tool
Function, boundary, failure, and explanation
- Function: try a normal example with a known result and confirm that the output can be copied, downloaded, or read as the page promises.
- Boundary: confirm whether input stays in the browser or must reach the it.you server or an outside data source.
- Failure: try empty, malformed, oversized, and unsupported input where relevant. The page should fail clearly, without presenting a partial result as certain.
- Explanation: check that the visible instructions, examples, privacy note, and limitations match what the interface actually does.
Browser and server boundaries
Where the input goes matters
| Tool type | Processing | What to verify |
|---|---|---|
| Formatter, converter, generator, timer, or image utility labelled “Runs in browser” | Client-side JavaScript in the open page | The tool input is not submitted to the it.you application server. |
| DNS, WHOIS, or IP lookup | Server-assisted request to a resolver, registry source, or IP-information provider | The requested domain or address leaves the browser, and the result can be stale, incomplete, or unavailable. |
| Account or support feature | it.you server and database | The form identifies what is stored and links to the privacy policy. |
A browser-only label describes the it.you application path. It does not remove browser extensions, managed-device software, or local network monitoring from the visitor's environment. Do not enter live secrets merely because a page runs client-side.
How correctness is checked
Use expected results, not visual confidence
A practical check begins with a small input whose result is already known. For a converter, compare a round trip where that operation is reversible. For a parser, use one valid and one invalid sample. For a calculator, check boundary values and compare important output with an independent implementation or primary specification.
Network and registry lookups need a different test. Their data changes and may come from third parties, so the page should identify the type of source and avoid claiming that one response proves ownership, location, reachability, or security.
Release and change checks
A passing page must remain crawlable and usable
Site release checks render public routes and look for broken responses, missing titles or descriptions, multiple H1 headings, malformed schema, missing form labels, images without alternatives, broken internal links, and inconsistent canonical URLs. Tool-specific behaviour still requires a human check in a real browser, especially for downloads, canvas output, drag-and-drop controls, keyboard use, and mobile layouts.
Changes that affect public behaviour belong in the changelog. Planned work belongs on the roadmap and must not be described as an available feature.
Limits and safe use
When to use an authoritative source
- Confirm production network changes with the relevant provider, registry, or system owner.
- Verify cryptographic and security decisions against current standards and an approved security process.
- Keep passwords, private keys, access tokens, personal data, and confidential customer data out of online tools unless your organisation has approved that use.
- Save a reproducible input and expected result when reporting a calculation or formatting bug, but replace sensitive values with safe examples.
Quick answers
Does every tool run in the browser?
No. Most formatters, generators, converters, timers, and image utilities do. DNS, WHOIS, and IP lookups need server-assisted access to external data. Each tool page should state the boundary.
Does a passing check guarantee a correct result?
No. It reduces common errors but cannot cover every browser, input, data source, or future change. Verify high-impact output independently.
How can I report a wrong result?
Use the contact form. Include the exact tool URL, safe sample input, expected output, actual output, browser, and steps to reproduce the issue.
How are accessibility problems handled?
Our accessibility statement explains the WCAG 2.2 AA design target, known limitations, and reporting details. A keyboard or screen-reader blocker on a core task should be reported as a bug.