Methodology
How we measure
Every diagnostic on TechUtilityTools is browser-based and runs on the visitor's device. Nothing is faked, simulated, or estimated server-side. This page documents how each measurement works and what it can and cannot tell you — so you can interpret results with full context.
How our speed tests work
Our speed tests run in your browser using the standard fetch API against well-connected public CDN edges (Cloudflare and similar). Download throughput is measured by timing the receipt of a large file; upload by timing the transmission of generated data; latency by timing small HEAD requests. We perform multiple samples and report aggregated values rather than a single peak.
Because the tests run in the browser, they are limited by browser overhead, JavaScript engine performance, and any browser-level throttling. A native test client can sometimes squeeze 10-15% more throughput out of the same connection. We document this trade-off rather than hiding it.
How we measure latency, jitter, and packet loss
Latency is measured as the round-trip time of small HTTP HEAD requests to the test endpoint. We run multiple samples and report the median.
Jitter is the standard deviation of those samples — the variation between consecutive measurements.
Packet loss is approximated in the browser by measuring missing/failed requests in a burst, since browsers cannot send raw ICMP. This is a useful indicator but is not equivalent to a native ping packet-loss measurement.
How DNS lookups work in our tools
Our DNS lookup uses DNS-over-HTTPS (DoH) against Cloudflare's public resolver. This means results reflect what Cloudflare's resolver sees globally, not necessarily what your local ISP resolver would return. For most domains the answers are identical; for split-horizon DNS or geo-fenced records, they may differ.
How uptime, status, and API checks work
These checks make a single HTTP request to the target from your browser and report status, response time, and basic timing breakdowns. They do not run from multiple regions and do not represent multi-region availability. For continuous, multi-region monitoring, our paid monitor tier runs from server-side checkpoints.
Accuracy limits & what we can't see
- Browser-based tests cannot bypass JavaScript engine overhead or browser sandboxing.
- Wi-Fi signal strength and channel quality are measured by your device, not the test.
- We cannot see your ISP's internal routing decisions, only the result.
- Packet-loss approximation in the browser is less precise than native ICMP-based tools.
- Single-shot speed tests vary 20-30% naturally; trends matter more than any one result.
Data collection during tests
Test workloads (the bytes downloaded and uploaded) are exchanged with public CDN edges. We do not store the contents of those transfers. We record anonymized result metrics (numbers — throughput, latency, etc.) used to render your result page and, optionally, your account history if you're signed in. See our privacy policy for the full data flow.
How to interpret your results
- Compare against your plan's advertised speeds, not best-case marketing numbers.
- Run multiple tests over a day and look at the median — single results are noisy.
- Wired and wireless results will differ; both are useful for different reasons.
- Latency under 50 ms and jitter under 20 ms is good for almost any consumer use case.