How to use this test
- Close other downloads. Anything else using the connection competes directly with the measurement.
- Use a wired connection if you can. Testing over Wi-Fi measures your Wi-Fi, which is usually the real bottleneck rather than your line.
- Run the test. Latency first, then download at rising file sizes, then upload. It takes about a minute.
- Read latency and jitter, not just speed. For calls and gaming those two matter far more than the headline megabits figure.
Speed is the least important number here
Bandwidth decides how long a large file takes. That is genuinely all it decides. Almost every complaint about a connection "feeling slow" is actually about latency, jitter or loss — and none of those appear in the megabits figure people quote at each other.
| Measurement | What it governs | Good |
|---|---|---|
| Download | How fast large files arrive | 50+ Mbps |
| Upload | Video calls, cloud backup, streaming out | 10+ Mbps |
| Latency | How responsive everything feels | under 60 ms |
| Jitter | Whether calls and games feel steady | under 20 ms |
| Packet loss | Stalls, stutter, rubber-banding | 0% |
A 1000 Mbps connection with 15% jitter is worse for calls and gaming than a 40 Mbps connection with steady latency. This is the single most useful thing to understand about home networking.
How we measure, and why it matters
Three implementation choices make a real difference to whether the numbers mean anything:
- Rising transfer sizes. A small download finishes before TCP has finished ramping up. Testing only with small files reports a figure well below your real throughput; testing only with huge ones takes forever on slow connections. We ramp through several sizes and take the best.
- Discarding the start of each transfer. The first portion of any connection is TCP slow-start, where throughput is deliberately conservative. Including it drags the average down, so we measure the steady-state portion.
- Median latency plus spread. A single ping is noise. We send twelve and report the median alongside the variation, because the variation is what you actually feel.
Diagnosing a bad connection
Work through these in order — they are arranged by how often they turn out to be the answer.
- Test wired before blaming your provider. Wi-Fi is the bottleneck far more often than the line is. If a cable fixes it, your problem is wireless.
- Move to 5 GHz. The 2.4 GHz band is crowded by neighbours, microwaves and cordless phones. 5 GHz travels less far but is dramatically cleaner.
- Check nothing else is using the connection. Cloud backup, game updates and another device streaming will all saturate an uplink and inflate latency badly.
- Inspect the cable and connectors. A damaged or poorly seated cable causes loss rather than slowness, and loss is worse.
- Enable QoS or Smart Queue Management. If your router offers it, it specifically targets the latency spike that occurs when the connection is busy — which is the actual cause of "the internet gets bad when someone downloads something".
- Test at different times. Evening congestion is real. A connection that is fine at 10am and poor at 8pm is a contention problem, and that is worth reporting to your provider with figures.
Related tests
If calls are the problem rather than the connection, check the microphone test and webcam test — poor call quality is more often a local audio problem than a network one. System information shows the browser’s own connection estimate, and why it should not be trusted.
Frequently asked questions
Why is my speed lower than what I pay for?
Several reasons, most of them normal. Providers quote a maximum rather than a guarantee. Wi-Fi commonly halves throughput compared with a cable. Evening congestion is real and affects everyone on your local segment. Your router, your network card, or an old cable can all cap below your line speed. Test wired at a quiet hour before concluding your provider is at fault.
What is jitter and why does it matter more than speed?
Jitter is how much your latency varies between packets. Steady 40 ms feels fine; latency swinging between 20 and 120 ms feels terrible even though the average looks acceptable. Real-time applications have to buffer for the worst case, so jitter directly causes choppy calls and inconsistent game feel. It is invisible in the download figure everyone quotes, which is why so many people with "fast" connections have bad calls.
What causes packet loss?
Wi-Fi interference is the most common by far — neighbouring networks, microwaves and cordless phones all crowd the 2.4 GHz band. After that: a damaged cable or connector, an overloaded router, or a genuine line fault. Packet loss is much more damaging than low bandwidth, because lost data must be detected and retransmitted, which stalls everything. Even one or two percent is a real problem worth chasing.
How much speed do I actually need?
Less than most people assume. HD video streaming needs about 5 Mbps, 4K about 25. A video call needs 2 to 4. Online gaming needs almost nothing in bandwidth terms — well under 1 Mbps — but is extremely sensitive to latency and jitter. Above roughly 100 Mbps, extra bandwidth mainly reduces how long large downloads take and changes nothing about how responsive anything feels.
Why does this send data to Cloudflare?
Because measuring throughput requires actually moving data to and from a server — this is the one test on the site that cannot run locally. We use Cloudflare’s public measurement endpoints, which exist for exactly this purpose. Your IP address is visible to them during the test, as it would be with any speed test. Nothing else about you is shared.
Why do different speed tests give different results?
Server location, test duration, number of parallel connections and how much of the transfer is counted all differ between tools. Tests using many parallel streams report higher figures than single-stream tests, because parallel connections work around per-connection limits. Neither is wrong; they measure different things. Compare a tool against itself over time rather than against other tools.