Guide
How a speed test works
What the four numbers mean, and why the result rarely matches the number on your bill.
What a speed test is actually doing
A speed test is not a query. There is no server that knows how fast your connection is and can be asked — the only way to find out is to move real data and time it. Everything else follows from that.
The test opens several connections to a measurement server and transfers as much data as it can for a fixed period, then divides bytes by seconds. Multiple parallel connections are used deliberately: a single TCP connection is limited by its window size and the round-trip time, and on a fast line with any distance involved one stream cannot fill the pipe. Several streams together can, which is also how real download managers and video players behave.
Latency is measured separately and first, with small requests timed individually before the bandwidth phases begin — because once the link is saturated, latency measurements would reflect the queue the test itself created rather than the idle state of the connection.
The four numbers
| Metric | What it measures | What it affects | Unit |
|---|---|---|---|
| Download | How fast data arrives | Streaming, browsing, downloads, updates | Mbps |
| Upload | How fast data leaves | Video calls, backups, publishing, gaming | Mbps |
| Latency | Round-trip delay for one packet | Responsiveness, gaming, call quality | ms |
| Jitter | Variation in that delay | Call and stream stability | ms |
Megabits and megabytes
Connections are sold in megabits per second; files are measured in megabytes. There are eight bits in a byte, so a 100 Mbps connection downloads at roughly 12.5 MB/s at best. A great many complaints that a connection is “eight times slower than advertised” are this conversion, and nothing else.
Why your result comes in under your plan
The number on your bill describes the capacity of the line delivered to your property under ideal conditions. A speed test measures the whole path from the application on your device to a server somewhere on the internet and back. Every step in between can reduce the figure.
| Cause | Effect |
|---|---|
| Wi-Fi | Frequently the largest single loss, especially on 2.4 GHz or through walls |
| Router age | Older hardware cannot route at gigabit speeds regardless of the line |
| The device itself | A busy or old machine cannot receive as fast as the line delivers |
| Peak-hour congestion | Shared capacity in the local segment or at an interconnect |
| Distance to the server | Longer paths raise latency and cap what one connection achieves |
| Other traffic at home | A background upload or a console update competes for the same line |
Wi-Fi is usually the biggest of these and the easiest to rule out. A 2.4 GHz link through two walls can lose most of a gigabit connection before it reaches the device. If you want to know what your line can do, test once over a cable; if you want to know what your devices actually experience, test over Wi-Fi where you normally sit. Both are worth knowing, and comparing them tells you where the problem is.
Latency is not affected by speed
Upgrading from 100 Mbps to 1 Gbps does not reduce latency. Bandwidth is how much data can be in flight; latency is how long a single packet takes to make the trip, and that is governed by distance, the number of hops and how much queuing happens along the way. A gigabit connection to a server on another continent will still show 150 ms, and the responsiveness of anything interactive is dominated by that number rather than by throughput.
This is why a fast connection can still feel sluggish. Loading a page involves dozens of small round trips — DNS, TLS handshakes, sequential resource requests — and each one pays the latency cost in full. Bandwidth only starts to matter once something large is actually being transferred.
Bufferbloat: the latency that only appears under load
A connection can show excellent idle latency and become unusable the moment something starts downloading. The cause is oversized buffers in home routers and provider equipment: rather than dropping packets when a link is full, they queue them, and a full queue adds hundreds of milliseconds of delay to everything sharing the link. Idle latency looks fine because the queue is empty. This is why a video call degrades when someone else in the house starts a large download, even on a fast line.
Testing well
A single result is a data point, not a measurement. Conditions change: peak hours differ from early mornings, Wi-Fi varies by room, and a background update can consume the line silently. The useful practice is to test a few times under conditions you can describe, keep the results, and compare like with like.
Keeping a short history is what turns a number into evidence. If a connection has run at 300 Mbps for weeks and today reads 40, that is a fault worth reporting with dates attached. If it has always read 40 despite a 300 Mbps plan, that is a different conversation and one you can now have with specifics. Either way, a record beats a recollection — which is why the speed test on this site keeps the last ten results in your own browser, with nothing about the connection they were measured on.
Frequently asked questions
Why is my result lower than the speed I pay for?
Usually because the advertised figure is a ceiling for the line into your home, and a speed test measures the whole path end to end. Wi-Fi, the age of your router, the device running the test, congestion at peak hours and the distance to the test server all subtract from it. The advertised number is also in megabits per second while file managers report megabytes — a factor of eight that accounts for a great many confused comparisons.
Should I test over Wi-Fi or a cable?
Both, and the difference between them is the most useful thing the test tells you. If a cabled test reaches your plan speed and Wi-Fi does not, the bottleneck is inside your home and no amount of arguing with your provider will change it. If both fall equally short, the problem is upstream. Testing only over Wi-Fi and concluding your line is slow is the single most common mistake.
What is jitter, and why does it matter more than speed for calls?
Jitter is the variation in latency between packets. A call needs packets to arrive at a steady rate; when they arrive unevenly the receiver either waits, adding delay, or plays what it has, producing gaps. A connection with 400 Mbps and 60 ms of jitter will sound worse on a video call than one with 20 Mbps and 3 ms. Speed is about how much you can move, jitter is about how predictably.
Why do two speed tests give different answers?
Because they measure different paths. A test server hosted inside your own provider’s network measures the segment between you and them, which is usually the fastest possible result. A server on the wider internet includes the interconnects between networks, which is where congestion generally lives. Neither is wrong; they answer different questions, and the gap between them is often the interesting part.
Does a speed test use a lot of data?
Yes — that is what it measures. A full test typically transfers a few hundred megabytes on a fast connection, because measuring throughput accurately requires actually saturating the link for several seconds. On a metered or mobile plan this is worth knowing before running one repeatedly.
Why does the number climb during the test rather than appearing at once?
Because TCP starts cautiously. A connection begins with a small congestion window and grows it as it establishes that the path can carry more, a process called slow start. Reaching full throughput takes a second or two, which is why a test needs to run long enough to get past that ramp and why very short tests systematically under-report fast connections.
Try it yourself
Everything above is easier to follow against a real answer.