You run Ookla's Speedtest. It says 300 Mbps. You open fast.com. It says 180. You try the connection quality tool on this site. It says 60. Three measurements of the same connection, taken within sixty seconds of each other, three wildly different answers. Which one is right?
All three are right — for different definitions of right. Each is measuring a different thing under a different methodology, and the spread between them isn't an error. It's the gap between marketing throughput, streaming throughput, and real-world single-stream throughput. Once you know what each tool is doing, you can pick the one that answers your actual question.
The speed-test economics
Commercial speed tests have a commercial incentive: they need to feel impressive. A test that returns small numbers gets uninstalled. So the popular tests run multi-server, multi-stream tests against infrastructure specifically provisioned for the test — geographically close, peering-optimised, often hosted inside the user's ISP. The result is a number that maxes out the line, which is exactly what the ISP wants you to see when you're verifying you got what you paid for.
Ookla in particular is worth knowing about: in many regions its test servers are donated and operated by ISPs. That doesn't mean the numbers are fraudulent, but the methodology — multi-stream, ISP-hosted endpoint, short duration — is designed to flatter. It's the same reason car manufacturers quote 0-60 times instead of real-world acceleration: technically true under controlled conditions, not what you experience on a Tuesday morning.
fast.com is Netflix's tool. It tests against Netflix's own CDN, with the implicit message: this is how fast Netflix will be for you. Useful if that's the question you're asking. Less useful as a general throughput measurement, because it's only checking the path between you and one specific provider.
What connection-quality on this site actually does
The connection quality tool on this site pulls a single ~5 MB file from Cloudflare's public speed endpoint. One TCP connection. One stream. No parallelism, no warm-up, no geographic optimisation beyond Cloudflare's normal anycast routing. The number you see is what a real single-stream download — a file from a CDN, a video stream, a software update — would actually achieve right now.
That's almost always lower than a multi-stream test, because TCP's congestion-control algorithm takes time to ramp up to full speed (the "slow start" phase), and a 5 MB file often finishes before a single stream reaches the line's peak. Multi-stream tests work around that by running 8 or 16 parallel connections, each ramping up in parallel; the aggregate hits the line's cap. Our single-stream test is honest but unflattering. It tells you what one download will do, not what eight concurrent downloads will do.
For most real-world questions, single-stream is what you want. A YouTube video is a single stream. A Steam game download is usually one or two. A Microsoft Teams call is one. Web pages are typically served by a handful of parallel connections, but each individual asset is still single-stream. The cases where you genuinely care about aggregate parallel throughput are narrow: backup tools, BitTorrent, running a CDN edge yourself.
The Network Information API — the browser's own guess
Modern browsers expose navigator.connection.downlink, a rough estimate of your current throughput. It's not measured by running a test; it's inferred from the last few seconds of network activity the browser saw. Useful as a sanity check, never authoritative. The value updates as the browser sees more traffic, and on an idle connection it's basically a guess.
The tool on this site shows the browser's estimate next to the measured value. When they agree, you've got a stable connection. When they disagree by 5x, your connection is fluctuating — either capacity is changing second to second, or the browser had stale data, or you're sharing a Wi-Fi channel with a neighbour who just started downloading something large.
Throughput vs latency — they're independent
A 1 Gbps fibre line with 200 ms latency to your nearest CDN will feel worse for interactive work than a 50 Mbps line with 10 ms latency. Speed tests measure throughput. They don't capture latency, and they don't capture jitter. For video calls, SSH sessions, online games, and anything else interactive, latency matters more than Mbps once you're past about 25 Mbps.
This is why "upgrade your internet" is often the wrong fix for a slow-feeling connection. If your line is already 100 Mbps and a Zoom call is choppy, doubling to 200 Mbps will not help — the call only uses 2-3 Mbps. What's actually hurting the call is jitter and packet loss, which a ping check will spot in ten seconds and a speed test will miss entirely.
The same principle applies to web browsing. Above about 50 Mbps, page load times are dominated by round-trips, not bandwidth. A page that needs to fetch 30 separate resources from a server with 100 ms latency takes at least three seconds — and no amount of extra bandwidth will speed that up. That's why HTTP/2 and HTTP/3 exist: they reduce the round-trip cost by multiplexing requests over a single connection, which buys you more than another 100 Mbps would.
When the difference between speed tests matters
Buying broadband. Run three different tests over a week, at different times of day, and take the median. One peak-time test on one tool doesn't tell you anything about typical performance.
Diagnosing a slow site. Throughput is usually a red herring. Check ping first. If latency and loss are normal but a specific site is slow, the problem is on their end, not yours. Throughput tests won't tell you that.
Verifying ISP claims. Use a multi-stream tester aligned with the ISP's measurement methodology — usually Ookla — because that's the methodology any complaint will be measured against. Single-stream numbers are honest but ISPs will dismiss them as not reflecting the line's capacity.
Choosing a video conferencing tool. Throughput is largely irrelevant. Latency, jitter, and packet loss are the metrics that matter. A 25 Mbps connection with 10 ms ping and zero loss outperforms a 500 Mbps connection with 50 ms jitter and occasional drops.
When to use the connection-quality tool here
The connection quality tool gives you a real single-stream number. No marketing optimisation, no multi-stream trick, no third-party tracking, no app to install. Run it when you want to know what a single file download or a single video stream will actually achieve on your current network, right now. Pair it with the ping check if you also want to know whether the connection is steady.
Related reading
For the latency side of the picture, reading ping results walks through what latency, jitter, and packet loss each mean and which one breaks which workload. The what is my IP page is the fastest check that you're online at all, before any of these other questions become relevant.