This downloads a real ~3MB file from this site's own server, in your browser, over several connections at once, reading each in small streamed chunks rather than waiting for the whole thing — that's what makes the live chart possible. Every ~150ms it records how many bytes arrived since the last checkpoint, converts that to megabits per second, and plots it. The instantaneous line is genuinely noisy — that's real network jitter, not a rendering artefact — so a rolling moving average is layered on top to show the trend a single number would hide. Upload runs the same way in reverse, sending real data to a small serverless function on this site. Latency is measured the same honest way: several small round-trip requests to this site, timed directly.
A measured 120 Mbps download comfortably covers 4 simultaneous Netflix 4K streams (25 Mbps each, per Netflix's own published minimum) with headroom to spare, downloads a 15GB 4K movie in about 17 minutes, and pulls down a modern ~100GB GTA V install in a little over 1 hour 51 minutes — assuming the connection holds that speed the whole time, which real connections rarely do perfectly.
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 it 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.