Why is my speed test result lower than the speed I pay for?

The usual suspects, in order of likelihood, are Wi-Fi, other devices using the connection, and distance to the test server. Test again over Ethernet with everything else idle. If the wired result matches the plan, the shortfall is inside your home, not on the line.

Why do different speed tests give different numbers?

They use different servers, different numbers of parallel connections, different payload sizes, and different ways of discarding slow-start. Tests that pick a server inside your own ISP report higher numbers than tests that measure across the internet. Neither is dishonest, but they answer different questions.

What speed do I actually need?

Roughly 5 Mbps for one 1080p stream, 25 Mbps for 4K, and under 5 Mbps for video calls. Almost every household complaint about speed is really about latency, jitter, or Wi-Fi coverage rather than about the headline figure.

Does a VPN slow down my speed test?

Usually, yes. Traffic takes a longer path through the VPN exit, adding latency, and encryption adds overhead. A well-provisioned provider on a nearby server costs a modest amount of throughput. A distant or overloaded server can cost most of it.

Why only three runs a day?

A speed test moves real bytes, and those bytes cost money to serve. Three runs is enough to check a connection and to compare before and after a change. Repeated automated running is a bandwidth drain with no diagnostic value.

Internet Speed Test

Measure download and upload throughput plus latency and jitter from this browser, three runs a day.

Three runs a day. Measured against our edge location nearest to you (CMH), not against a server inside your own provider.

Nothing measured yet

The run takes about thirty seconds: 8 latency samples, then 1, 10 and 25 MB downloads, then a 8 MB upload. Payloads are random bytes with no-store, so nothing in the path can answer from a cache.

The test times payloads in your browser, so it needs JavaScript. Everything below about how the measurement is taken, and what the numbers do and do not prove, is rendered on the server.

What the run actually does

Latency. 8 one-byte requests, plus a warm-up request that is thrown away, so the first connection cost does not land in the median.
Download. Payloads of 1, 10, 25 MB of random bytes withCache-Control: no-store and an explicit Content-Length. Random bytes do not compress, so no proxy can inflate the figure.
Upload. 8 MB generated in your browser and posted to a Worker that counts the bytes and discards them. Nothing is written anywhere.
Throughput. Computed in your browser from bytes moved and the time between the first byte and the last, so connection setup is not counted as transfer time.

What this measures, and what it does not

The far end is our edge location nearest your network, not a server inside your own provider and not a server on the far side of the internet. That makes the figure a fair measure of the path from your device to a very well connected point, and an optimistic measure of a transfer to any particular website.

Tests run by an ISP against a server on its own network usually report higher numbers, because the traffic never leaves that network. Neither number is dishonest. They answer different questions, and the question this page answers is how well your access network carries a real transfer.

How the measurement is taken

Download payloads are random bytes, generated in the Worker in 64 KB chunks or read from an object store when one holds a prepared file, and sent with Cache-Control: no-store and an explicit Content-Length. No cache anywhere in the path can answer without moving the bytes. Compressible content would inflate the result, so the payload is incompressible either way.

Three sizes run in sequence. The 1 MB pass mostly measures TCP slow start and is reported separately for that reason. The 25 MB pass is the number to trust on a fast connection, because it runs long enough for congestion control to settle.

Upload data is 8 MB generated in the browser and posted to a Worker endpoint that counts the bytes and discards them. The endpoint refuses anything above 25 MB in one request.

Where the ceiling comes from

Above roughly 1 Gbps, a browser-based test measures the browser rather than the link. JavaScript, TLS, and the single-machine CPU become the constraint before the network does. If your line is faster than that, use iperf3 against a server you control for a real figure.

Fair use

Three runs per day per source address, enforced as a hard stop rather than a slowdown. There is no queue and no paid tier. If you need repeated measurement, run your own iperf3 endpoint, which is the right tool for continuous monitoring anyway.

About this tool

Download throughput comes from fetching randomised payloads of 1, 10, and 25 MB with caching disabled, upload from posting generated data, and latency and jitter from a series of small requests. Your browser computes the figures from bytes transferred and elapsed time. The result covers your Wi-Fi and everything in between, not only the line you pay for. Three runs per day.

How to read the result

Download speed (Mbps): Megabits per second, computed from bytes received divided by the time between the first byte and the last, on one connection, so watch the unit, because 100 Mbps is about 12.5 MB per second. The 1 MB payload finishes before TCP congestion control reaches steady state, so the larger payloads give the more representative number.
Upload speed (Mbps): The same computation in the other direction. On cable and DSL upload is asymmetric by design and can be a twentieth of the download figure, so a low upload number is usually the plan rather than a fault.
Latency (idle): Round-trip time to the nearest edge, measured with small requests before the throughput phase, while the connection is quiet. This is the floor for anything interactive, and distance and the access technology set it.
Jitter: How much the response time varies between successive samples. High jitter with a normal average latency points at Wi-Fi interference, a congested access network, or bufferbloat, and it affects calls and games far more than raw throughput does.
Why the result is lower than your plan: A browser test measures the whole path, which is your Wi-Fi, the router, the access network, and the route to our edge, and Wi-Fi alone commonly halves a gigabit line. A single-server test also cannot saturate a very fast connection, because above roughly 1 Gbps the browser and the CPU become the limit rather than the link.

Questions people ask

Why is my speed test result lower than the speed I pay for?: The usual suspects, in order of likelihood, are Wi-Fi, other devices using the connection, and distance to the test server. Test again over Ethernet with everything else idle. If the wired result matches the plan, the shortfall is inside your home, not on the line.
Why do different speed tests give different numbers?: They use different servers, different numbers of parallel connections, different payload sizes, and different ways of discarding slow-start. Tests that pick a server inside your own ISP report higher numbers than tests that measure across the internet. Neither is dishonest, but they answer different questions.
What speed do I actually need?: Roughly 5 Mbps for one 1080p stream, 25 Mbps for 4K, and under 5 Mbps for video calls. Almost every household complaint about speed is really about latency, jitter, or Wi-Fi coverage rather than about the headline figure.
Does a VPN slow down my speed test?: Usually, yes. Traffic takes a longer path through the VPN exit, adding latency, and encryption adds overhead. A well-provisioned provider on a nearby server costs a modest amount of throughput. A distant or overloaded server can cost most of it.
Why only three runs a day?: A speed test moves real bytes, and those bytes cost money to serve. Three runs is enough to check a connection and to compare before and after a change. Repeated automated running is a bandwidth drain with no diagnostic value.

Last reviewed 2026-09-05.