Internet Speed Test

This test measures throughput with several connections at once, throws away the slow-start period, and reports the median of the stable interval rather than one convenient average. The full measurement detail is on the page so you can check the arithmetic yourself.

What a speed test can and cannot tell you

It measures one thing: how fast this device, over this connection, right now, can move data to and from the nearest edge location. That is a genuinely useful number, and it is not the same as the speed your provider sells you. Your plan describes the capacity of the line into the building. Everything after that point — the Wi-Fi hop, the router, whatever else in the household is streaming — sits between you and that number.

Wi-Fi is the most common bottleneck by a wide margin. A device two rooms away on a congested 2.4 GHz channel can measure a fraction of what the same connection delivers over a cable, and the line itself is not at fault. If the result surprises you, repeat the test on a wired connection or standing next to the router before concluding anything about your provider. Testing at a different time of day is worth doing too: shared access networks slow down in the evening peak.

How this test is measured

Four things make the difference between a defensible measurement and a number that merely looks plausible. First, multiple parallel connections: a single TCP stream is limited by round-trip time and window size, so on a high-latency line one connection cannot fill a fast pipe no matter how fast that pipe is. Second, the warm-up is discarded — TCP congestion control starts from a small window and grows, so the opening stretch of any transfer is slower than the steady state and including it drags the result down.

Third, the reported figure is the median of the stable interval, split into short buckets, rather than an average. An average lets one disrupted moment — a neighbour starting a download, Wi-Fi dropping a beat, a phone switching cells — move the headline number; a median does not. Fourth, the download material is cryptographically random bytes, which cannot be compressed. If the test data were compressible, any proxy between us could compress it in transit and we would measure the compressed byte count against the original size, producing a number several times higher than your real throughput. The result panel also shows total bytes, the measurement window, the discarded warm-up and every bucket, so the headline number can be recomputed from the raw data.

Latency and jitter matter more than the big numbers

Latency is the round-trip time for a single small request — how long the network takes to answer at all. Jitter is how much that time varies between consecutive samples. For anything interactive, these two govern the experience far more than throughput does. A video call needs only a few Mbps; what makes it break up is latency and jitter. Once you have enough bandwidth for what you are doing, more bandwidth changes nothing, whereas a jitter problem is immediately audible.

High jitter on an otherwise fast connection usually points at Wi-Fi interference or at bufferbloat, where an oversized queue somewhere on the path fills up during heavy transfers and delays everything behind it. A useful diagnostic: run this test while a large download is in progress. If latency climbs sharply under load, the line is not too slow, its queueing is badly behaved, and modern router firmware often has a queue management setting that fixes it.

The upload test is the one place we receive data

Breezo exists on the premise that your files never leave your device, and the upload measurement has to be squared with that honestly rather than glossed over. Measuring upload throughput requires something on the other end to send bytes to. There is no way around it, so this page does send data, and here is exactly what it sends.

The payload is random bytes generated in your browser at the moment of sending, using the browser cryptographic random generator. It is not a file, and it never touches your storage: this page has no file input at all, so there is nothing on it capable of reading a file even by mistake. On arrival the bytes are read in chunks and discarded — nothing is written to disk, nothing is forwarded, nothing is retained. The endpoint replies with a single number, the count of bytes it received, which the results panel compares against what your browser sent as a cross-check. Our acceptance script goes further and verifies, on every run, that the number of bytes generated by the random generator is at least the number of bytes posted — a test that would fail immediately if any code path ever tried to send something else.

Reading your result

Speeds are reported in megabits per second, the unit providers advertise. Your download manager shows megabytes per second, which is roughly one eighth of that figure, and confusing the two is the most common reason people believe they are getting a fraction of what they pay for. As rough guidance: a video call is comfortable from around 3 Mbps, high definition streaming from around 5, 4K from around 25, and large game or video downloads are the only everyday task that benefits from hundreds.

Two limitations are worth stating. The test stops at a fixed data budget so that it does not consume an unreasonable amount of a metered or mobile connection, which means on a very fast line the measurement window is short and the result is conservative rather than optimistic. And every measurement is a snapshot: a single number tells you far less than three runs at different times of day, particularly on shared or mobile networks where load varies hour to hour.