How to Read Speed Test Results
A speed test result is a snapshot of four measurements — download speed, upload speed, latency and jitter — taken between your device and one nearby test server, at one moment, over a connection that may have been busy with other things at the time. It is a useful snapshot, but it is not a verdict on your internet provider, and it is not a single number: a connection can be fast and still feel terrible, or modest on paper and perfectly smooth in use, depending on which of the four numbers is the weak one. This article explains what each number measures, what counts as good for browsing, video calls, gaming and 4K streaming, why the same line gives a different result every run, and how to turn a result into evidence your provider can actually act on. You can run a test yourself in the Internet Speed Test, which measures your connection to the nearest Cloudflare edge right in your browser.
The four numbers, and what each one actually measures
Download speed is throughput in one direction: how many megabits per second (Mbps) the test managed to pull from the server to your device, using progressively larger downloads and reporting a high percentile of the samples rather than a single peak. Upload speed is the same measurement in reverse — how fast your device can push data out — and it is the number that decides how your video looks to other people on a call, how quickly a backup finishes, and how long a large file takes to send. The two are often wildly asymmetric on home plans, and a slow upload with a fast download is a plan shape, not a fault.
Latency, often labelled ping, is the round-trip time for a tiny request to reach the server and come back, measured in milliseconds: it is the delay before anything starts moving, and it is what makes a connection feel responsive or sluggish. Jitter is the variation between consecutive latency measurements — how steady that delay is. A connection with 25 ms latency and 3 ms jitter feels crisp; the same 25 ms average with 40 ms jitter feels stuttery, because video frames and voice packets arrive unevenly. As a rough guide: web browsing is comfortable from about 10 Mbps down with latency under 100 ms; a group video call wants roughly 3–8 Mbps each way with latency under 150 ms and jitter under 30 ms; online gaming cares little about raw speed — 5–10 Mbps is plenty — but wants latency under 50 ms and jitter under 20 ms; and a single 4K stream typically needs around 25 Mbps of sustained download. Divide Mbps by 8 to get megabytes per second, the unit your browser’s download indicator uses.
Why the same line gives a different number every time
A browser speed test measures the whole path, not just your provider’s line: your device, your Wi-Fi, your router, the line to the exchange, your provider’s network, and the route to the test server. Any of those can be the bottleneck on a given run. Wi-Fi is the usual suspect on fast connections — it rarely delivers the full line rate, and it degrades with distance, walls, and neighbouring networks — followed by other devices on the same connection, background updates and cloud syncs, the browser itself on a busy machine, and the time of day: evenings, when the neighbourhood is streaming, are the shared network’s rush hour. Server distance matters too, which is why this test measures against the nearest Cloudflare edge rather than a server on another continent.
Methodology adds a second layer of difference. Tests disagree on file sizes, on whether they open one stream or several, on which percentile they report, and on whether the test server sits inside your provider’s network (on-net, shorter path, flattering numbers) or outside it (off-net, closer to real browsing). There is no single standard definition of internet speed, so numbers from different testers are not directly comparable — a 400 Mbps result from one and 300 Mbps from another can both be honest measurements of different things. A single slow run proves neither congestion nor throttling: only a pattern, measured the same way over several days, can support either claim.
Why the test can look fine while the app stutters — or the reverse
A speed test measures the path to one test server. Your video call, game, or stream connects to different servers, often in different cities, reached over different routes — and those routes can be congested while the test path is clear, or the other way round. Throughput is also only part of the story for real applications: most of what you do online is small transfers, and small transfers are limited by latency, not bandwidth, because each round trip waits on acknowledgements before more data is sent. That is why a 500 Mbps connection can still load pages slowly if latency is high, and why a modest 50 Mbps connection with 15 ms latency can feel instant. Idle latency alone does not tell the whole story either: latency under load — how delay grows while the connection is busy — is what decides whether a call glitches when a download starts.
So treat a mismatch as information, not a contradiction. If the test is healthy but one app is not, the problem is likely beyond your line: that app’s servers, the route to them, or something on the device. Checking the same destination from many places around the world, as in Is It Down or Is It Just You?, separates a local problem from a global one. If every app stutters while the test looks fine, look at what the test does not measure: loaded latency, packet loss, and what else was using the connection when the stutter happened. And if the test is slow but apps feel fine, the test path or the moment — not your everyday experience — may be the odd one out.
How to run a test you can actually trust
Decide what you are testing before you start. To test the line itself, use a wired Ethernet connection, one device, and nothing else running: close streaming, pause cloud sync and updates, and close other browser tabs. To test the Wi-Fi in a room, test from that room, on the device you actually use there — but then the result describes the room, not the line, and should not be quoted to your provider as line speed. Run the test at least three times and take the median, not the best; test at different times of day, including the evening peak; and keep the conditions the same between runs you intend to compare. A single result is a snapshot; a set of comparable results is evidence.
Note the conditions alongside the numbers — wired or Wi-Fi, time of day, what else was running — and keep a short log over several days if you are building a case. One full test can move a significant amount of data, up to roughly 200 MB, so avoid running repeated tests on a metered or capped connection. Export or screenshot each result with its timestamp; the Internet Speed Test on this site offers a CSV export for exactly this purpose, so a week of comparable numbers can be shown to a provider in one file instead of argued from memory.
What a speed test cannot tell you
A speed test reports symptoms, not causes. It cannot say why packets are lost — whether the cause is Wi-Fi interference, a faulty cable, a congested link, or a failing modem — and it cannot measure bufferbloat, the latency swelling under load, unless it specifically probes latency while the connection is saturated. It cannot split the path into home network and provider network from a single run: a slow Wi-Fi result and a slow line result look identical in the four numbers, and only a wired comparison separates them. It also cannot see inside your home network at all — which device is hogging bandwidth, whether the router is overheating, or whether a neighbour’s network is trampling your Wi-Fi channel.
It cannot diagnose problems that are not about the connection, either. A site that blocks or throttles you because your IP address has a poor reputation will feel broken no matter how fast the test reads; that is a reputation problem, explained in Why Your IP Address Gets Flagged, and no amount of bandwidth fixes it. Nor can a test distinguish deliberate throttling from ordinary congestion — both look like a slower number — or tell you whether a slow site is slow for everyone. For those questions, combine tools: compare wired against Wi-Fi, test the same destination from many locations with the Global Ping tool, and look for a pattern over time before drawing a conclusion.
When to call your ISP — and which numbers to quote
Call when a pattern persists, not when a single result disappoints. The threshold for a real complaint is something like this: wired tests, on more than one day, at different times including off-peak, consistently well below your plan speed — under half is a strong signal — or latency and jitter that stay high on a wired connection when nothing else is using it. Restart the router once and retest before calling, so that step is already done. Do not open with a Wi-Fi result from the far bedroom: the first thing support will ask is for a wired test, and a complaint built on Wi-Fi numbers will be filed as a home-network problem.
Quote the numbers that let support act: your plan speed, the median of at least three wired tests with dates and times, the latency and jitter from those same tests, and what you ruled out — one device, no background traffic, router restarted. Say whether the problem is constant or time-of-day dependent, because evening-only slowness points at shared-network congestion while all-day slowness points at the line or the equipment. Ask for a line check and a fault ticket number, and keep your exported results: a calm list of comparable numbers, gathered the same way over several days, is far harder to dismiss than one angry screenshot.