Methodology · technical transparency

How we actually measure your connection

A speed test shouldn't be taken on trust. Here is all of it: which servers we measure against and why, how long each stage runs, how the final number is calculated and — above all — what this measurement cannot tell you. That last part is missing almost everywhere, and it is the part that matters when you are deciding whether to complain to your provider or replace your router.

In two lines: the test runs in your browser against Cloudflare's public infrastructure, takes about twenty seconds in total, and reports a stable figure calculated from percentiles rather than an average. We don't use servers hosted inside operator networks, because a server inside your provider's network returns prettier numbers that are less true.

1. What we measure against, and why

The test queries Cloudflare's global infrastructure, spread across hundreds of data centres. Cloudflare routes the request to the point of presence nearest your address, so you measure the path you actually travel when you browse.

• Latency and jitter: https://speed.cloudflare.com/__down with an empty payload, to isolate round-trip time from transfer time.
• Download: the same endpoint with increasing payloads.
• Upload: https://speed.cloudflare.com/__up via POST.
• Server location: https://speed.cloudflare.com/meta.

Choosing neutral infrastructure is the single biggest difference from many popular tests, which measure against servers hosted inside the operator's own network. Those servers flatter the result because the traffic never leaves the provider: it is like timing a car downhill.

2. How long the test takes

About twenty seconds in total:

• Latency: 12 consecutive measurements, preceded by a warm-up request that only opens the connection (DNS, TLS) and is discarded.
• Download: 8 seconds.
• Upload: 9 seconds.

What is fixed is the time, not the volume of data: on a slow line less data moves, but the measurement lasts the same. That is why the test still works on a poor mobile connection, where fixed-volume tests often give up.

3. Ping and jitter

We make 12 consecutive requests with an empty payload and time each round trip. Then:

• Ping = the lowest of the 12. Not the average: the minimum is the latency of the network when nothing gets in the way, which is the physical characteristic of the link. Higher samples contain queueing, Wi-Fi contention and operating-system delays — useful information, but a different question.
• Jitter = the average variation between consecutive measurements. This is the number that matters for video calls and online gaming: a line with low ping but high jitter causes more trouble than one with a higher, steady ping.

We also show a trimmed average, calculated after discarding the best and worst sample, as an indication of typical latency.

4. Download

For 8 seconds we download payloads of increasing size — 1, 5, 10, 25 and 50 MB — measuring instantaneous throughput as the data arrives, using performance.now(). Each sample is bytes received × 8 divided by elapsed time, in Mbps.

The final figure is the 90th percentile of the last 60% of samples. Two choices, two reasons:

• We discard the first 40% because the connection is still ramping up at the start (TCP slow start) and the speed is artificially low. Including it would understate the line.
• We take the 90th percentile rather than the mean because a mean is dragged down by a single momentary stall, while a high percentile describes the speed the line sustains when it is working properly.

This is a declared choice, not a neutral one: it returns a slightly more optimistic figure than the arithmetic mean of the same samples. We would rather say so than hide it.

5. Upload

Upload is the hard part, especially on mobile. For 9 seconds we send blocks of data with these safeguards:

• Adaptive block size: starting at 256 KB and doubling while the network keeps up, to a maximum of 8 MB. If a block takes too long, the size halves. A fibre line isn't measured with blocks that are too small, and a mobile line doesn't choke on blocks that are too big.
• Parallel connections: 3 on desktop, 1 on mobile. On phones, parallel uploads get in each other's way and the result gets worse.
• Error tolerance: every send has its own time limit; if it fails, we retry with a smaller block. A coverage gap doesn't kill the whole test.

The final figure is the 75th percentile of the last 60% of samples — more cautious than download, because upload is inherently noisier. If we cannot collect a single valid sample, upload is reported as not measured rather than estimated: a missing figure beats an invented one.

6. The limits of this measurement

This is the section almost no test publishes, and the most important one. A low result does not automatically mean your provider is cheating you: in most cases the bottleneck sits between the router and your device, not between the router and the world.

• Wi-Fi versus cable. This is factor number one. On a 1 Gbps line, home Wi-Fi rarely exceeds 400-600 Mbps in practice, and with a router a few years old it stops well before that. If you want to measure the line, connect the computer to the router with an Ethernet cable. If you measure over Wi-Fi, you are measuring Wi-Fi.
• The device. A laptop with an 802.11n adapter will not exceed about 150 Mbps whatever the line does. The socket matters too: many cheaper computers still ship 100 Mbps ports, which cap the result at exactly that figure.
• The browser. The test runs as JavaScript in your browser, so the browser is part of the measurement. Very old versions, extensions that filter traffic, battery-saving modes and CPU-hungry open tabs all lower the result.
• Other devices at home. A TV streaming in 4K, a cloud backup in progress or a camera uploading footage all use bandwidth while you measure. The measurement is correct — it simply isn't the line's total capacity, it is what was left over.
• Time of day. Between roughly 8pm and 11pm the access network is busier and real speeds can drop noticeably. An evening test and a morning test tell two different stories, both true.
• VPNs. A VPN adds a hop: it lowers throughput and raises ping. Turn it off before measuring.
• A test is a snapshot. It describes the line during those twenty seconds, from that device, at that spot in the house. It says nothing about the rest of the day.

7. Comparing the result with your contract

The headline number you pay for is not the number to expect on screen. Contracts usually quote several different figures, and only one of them is enforceable:

• Maximum or "up to" speed — the limit of the technology, not a promise.
• Average speed — what the provider states as typical, often measured at peak time.
• Minimum guaranteed speed — the only figure a complaint can be built on. It is in the contract terms, usually far lower than people expect.

To compare sensibly: measure over an Ethernet cable, with other devices idle, repeating the test at different times across several days, and write the results down. If you sit consistently below the minimum guaranteed speed, you have a case.

One caveat you are owed: this measurement has no legal standing. In the UK, providers signed up to Ofcom's Broadband Speeds Codes of Practice must give you a minimum guaranteed speed and, if they cannot fix a shortfall within 30 days, let you exit the contract without penalty. In the US, the FCC's broadband labels require providers to publish typical speeds. In both cases the formal process relies on the provider's own or the regulator's measurements — RealMbps helps you decide whether starting that process is worth it, and rules out the domestic causes first.

8. How accurate is it

Honestly: we have not run a systematic comparison between RealMbps and national regulators' tools, so we do not publish a certified margin of error. That figure would be made up.

What we can say is how the measurement behaves. Under controlled conditions — cable, nothing else running, repeated tests — results are repeatable and consistent; download is more stable than upload, which fluctuates more by nature; and the variation you see between runs almost always comes from the factors in section 6, not from the algorithm. If you run the test three times over a cable and get wildly different numbers, the cause is inside your network, and that is already useful information.

9. How to verify what we say

The test code is JavaScript loaded by your browser, and it is not obfuscated. You can read it:

• press F12 to open developer tools, open the "Sources" tab and the file script.js;
• look for measureLatency(), measureDownload() and measureUpload(): they are exactly what this page describes.

If you find a discrepancy between this page and the code, that is our mistake: tell us and we will fix it. The sources behind the other data on the site are listed in data and sources.

10. What makes us different

• Neutral servers, not hosted inside your operator's network.
• No sign-up and no stored results, unless you choose to publish one to the leaderboard.
• An algorithm built for mobile too, where many tests understate or fail the upload.
• A fully declared methodology, limits included.