| When | Down | Up | Ping |
|---|---|---|---|
| No tests yet — run one to start a history. | |||
A real ~3 MB file from this site, over 5 connections at once, read in streamed chunks. Every ~150 ms it records the bytes that arrived and plots them, with a moving average on top.
The same method in reverse, to a small serverless function that discards the data. If it is unreachable the tool falls back to an estimate by connection type, and says so.
Idle latency, then the same round trips during the download. The difference is bufferbloat: how much your router queues under load.
The 4K, film and game estimates assume the whole file arrives at your tested speed. Treat them as a best case.
Your result depends on the route between you and this specific server. A different server, a different time of day or a different route your ISP takes can give a different number for the same connection. Run it a few times, at different times of day.
Your ISP plan is measured to your router. Wi-Fi adds its own bottleneck: walls, distance, interference from neighbours’ networks and the Wi-Fi standard your device supports can all cap you well below the wired speed.
A gigabit connection with 150 ms latency still feels laggy in a video call or a competitive game: those care how fast one small packet round-trips, not how many megabits you can push.
Plans are sold as “up to” a number: the maximum under ideal conditions, not a floor. Peak-hour congestion, network maintenance and distance from the local exchange all pull real speeds below it.
During a big transfer, routers often queue other traffic instead of dropping it, which delays everything else sharing the line. This tool measures it directly: latency during the download minus latency at idle. A big jump means your router or ISP queues aggressively under load. It is a real, well-documented behaviour, not a measurement error.
A connection that bursts to 300 Mbps for a second then drops to 40 has a high peak but a much lower typical experience than one holding steady at 150. The consistency score exists because two connections with the same average can feel completely different to use.
Every speed test measures against its own server, over its own route through the internet — different providers, different distances, different momentary congestion. None of them is "wrong"; they're measuring slightly different paths. Run a test a few times, at different times of day, for a realistic picture.
A tiny serverless function on this same site accepts the uploaded data, reads it to completion so the timing is genuine, and discards it immediately — nothing is stored or logged beyond a byte count. If that function is ever unreachable (some static deployments don’t include it), the tool falls back to a connection-type estimate rather than pretending to measure something it can’t, and says so clearly when that happens.
A single connection wastes real time waiting for each request’s round trip between transfers — verified this can eat over 60% of the measured time on a fast connection with a small file. Running several requests concurrently overlaps that dead time with other transfers actively in progress, the same technique Ookla, Cloudflare and fast.com all use, and it’s what makes a smaller, faster-loading test file possible without losing accuracy.
Real networks don't deliver data at a perfectly constant rate — TCP slow-start, other traffic on your line, Wi-Fi interference and router buffering all cause genuine second-to-second variation. The moving average exists specifically to show the underlying trend through that noise.
Because that's the honest ceiling — real downloads from services like Netflix or Steam also depend on that specific server's load, your Wi-Fi (not just your ISP plan), and other devices sharing your connection at the same time. Treat these numbers as a best case, not a guarantee.
On a very fast connection, an uncapped test would just keep downloading for the full test duration — which on a gigabit line could mean transferring close to a gigabyte for a single test. The cap keeps the measurement honest while keeping the actual data moved reasonable regardless of how fast your connection is.
It's what happens when your router or ISP queues traffic instead of dropping it during a big transfer — your download looks fine, but everything else sharing the connection (a video call, a game) gets delayed. This tool measures it directly by comparing ping times before and during the download, rather than just asserting it might be a problem.
Latency (ping) is how long a tiny request takes to reach the server and come back, in milliseconds. This test measures it with the line idle and again during the download: a large jump under load is bufferbloat. Jitter is how much the latency varies from one ping to the next, which matters more than the average for calls and games.
This page has changed in 192 archived releases, but each of those was a site-wide pass, so none is attributable to this tool on its own and none is listed here. That is not a claim that the tool never changed — a release that reworked many pages at once may well have altered this one too. The changelog has them.