How to test your internet speed accurately

Updated 22 September 2026 · SpeedMeter

Run three speed tests and you will get three different numbers. That is not a flaw — you are measuring a shared, variable system. Here is how to take a measurement that means something.

Before you test

1. Use a cable if you can. Wi-Fi is usually the bottleneck, so testing over it measures your Wi-Fi, not your connection. If you only ever use Wi-Fi, test both — the difference is the most useful number you will get.
2. Stop other traffic. Pause downloads, backups and streams, and check nobody else is mid-4K-film. Consoles update games silently in the background.
3. Close other tabs. The test runs in your browser and competes with everything else in it.
4. Turn off your VPN. It reroutes traffic through another server and encrypts it, which costs both speed and latency.
5. Test on a capable device. An old phone may not reach your plan's speed regardless of the connection.

Run more than one test

A single measurement is a snapshot of a system that changes minute to minute. Run three, a minute or two apart, and use the pattern rather than any one figure:

• Consistent results → trust them.
• Wildly variable → something is competing with you, or your Wi-Fi is unstable.
• Each test slower than the last → possible thermal throttling or a background transfer that started.

SpeedMeter keeps your last ten results in your browser so you can see the pattern without writing anything down.

Time of day matters

Most consumer connections share capacity with your neighbourhood. Peak hours — roughly 7pm to 11pm — are when contention shows up.

If you suspect congestion, test at 10am and again at 9pm on the same day. A large gap is evidence of an oversubscribed segment, and it is one of the few complaints providers can be held to, because it is specific and reproducible. Keep a log of timestamped results before you call.

Why two speed tests disagree

This is the most common question, and the answers are mundane:

• Different servers. A test server 20 km away will outperform one 2,000 km away. Distance costs throughput as well as latency.
• Different numbers of connections. Tests using more parallel streams report higher figures. Single-stream tests understate fast or distant links badly.
• Different handling of ramp-up. Tests that include TCP slow start in the average read lower than those that discard it.
• Server capacity. If the far end is loaded, you measure their limit, not yours.
• Provider prioritisation. Some networks historically gave well-known test servers preferential treatment, which flatters those results.

Neither number is lying. They are measuring different paths under different assumptions.

Reading the four numbers

Download

Compare with your plan, and expect 5–10% less from protocol overhead. Over Wi-Fi, expect considerably less. If a wired test reaches roughly 90% of your plan, your connection is working correctly.

Upload

On cable and DSL this is a fraction of download and that is normal. On fibre it should be close to symmetrical. Check it against your plan separately — providers rarely advertise it prominently.

Ping

Under 50 ms is good for most purposes. Remember that much of it is distance to the server, so a higher figure against a distant server is not itself a fault.

Jitter

Under 10 ms is healthy. High jitter with a good ping points at Wi-Fi interference or bufferbloat, both covered in our latency guide.

What a browser test cannot tell you

Being straight about the limits:

• Multi-gigabit connections will read low. A browser tab is bound by JavaScript, HTTP overhead and a limited number of connections. Above about 1 Gbps, no browser-based test — including this one — reflects the true capacity. Use a native tool such as iperf3.
• Latency under load is not measured. Ping is taken before the transfer, so bufferbloat stays hidden.
• Packet loss needs more samples than a short test provides. Use a sustained command-line ping.
• It measures one path — from your browser to our server. A different destination may behave differently.

If the result is worse than expected

1. Retest with a cable. If that fixes it, see why is my Wi-Fi slow.
2. Retest on another device, to rule that device out.
3. Test at a different time of day, to check for congestion.
4. Try a second speed test service, to rule out our server.
5. If a wired test is consistently well below your plan at all hours across multiple services, collect the timestamped results and contact your provider. Evidence is what gets an engineer sent out.

Run a test now, then run two more in the next few minutes. The pattern will tell you more than any single number.