How our speed test works

The test, step by step

1. Network environment. Our server reads the public IP address your request came from. In parallel, the browser contacts an IPv4-only and an IPv6-only address check to see which protocols work end to end.
2. Server discovery and selection. Every configured test server receives one warm-up request and then four latency probes. The server with the best score (below) is used.
3. Idle latency. Two warm-up requests open the connection, then 20 empty requests measure round-trip time.
4. Download, with latency probes running at the same time.
5. Upload, with latency probes running at the same time.
6. Packet loss, only where the server provides a WebRTC relay.
7. Validation and analysis. Ramp-up periods are excluded, outliers are handled as described below, and the result is assembled with warnings for anything unusual.

How download speed is measured

Download speed is the number of bytes received during the stable part of the test divided by the time taken, converted to megabits per second (1 Mbps = 1,000,000 bits per second).

• Data is streamed over several parallel HTTPS requests. The test starts with 2 and adds streams as speed increases (4 above 10 Mbps, 6 above 50 Mbps, up to 8 above 200 Mbps), because a single connection often cannot fill a fast line.
• Request sizes adapt so each request lasts about 1.5 seconds — from 128 KiB on slow mobile links up to 50 MB on gigabit fibre.
• Bytes are counted as they arrive, using the browser's high-resolution clock, in 250 ms windows.
• The first part of the test, while TCP/QUIC is still speeding up (“slow start”), is detected and excluded — at least 1 second, at most 40% of the test.
• The phase runs at least 5 s and at most 15 s. It ends early only when the last two seconds are within 5% of the two seconds before and window-to-window variation is low. Noisy connections run the full duration.
• The reported speed is the average over the stable period — not the peak, and not the best windows — so it cannot overstate your connection.

How upload speed is measured

Upload speed counts only data the server confirmed it received, over the stable part of the test, measured separately for each parallel stream and added together.

• The payload is random, incompressible data generated in your browser. Your files are never read or sent.
• Streams (2–6) and request sizes (64 KiB–34 MB) adapt to your speed just as for download.
• Browsers report upload progress when data is handed to the operating system, which can run ahead of the network. We therefore use server acknowledgements for the result and progress events only for the live gauge.
• On extremely slow links where too few uploads complete, the result falls back to bytes sent and is marked with a warning.

How ping, jitter and latency under load are calculated

Ping is the median round-trip time of 20 small requests after warm-up. Jitter is the average absolute difference between consecutive pings. Latency under load is the median ping measured while the download or upload is running.

• Where the server allows it, timing uses the browser's Resource Timing API (time from sending the request to the first response byte), minus the server's own processing time reported in the Server-Timing header. Otherwise the browser's wall-clock time is used; the result states which method applied.
• Only extreme spikes are treated as outliers: values above the upper quartile plus three times the interquartile range, and never more than 10% of samples. Normal variation stays in, so an unstable connection shows high jitter instead of being cleaned up.
• During bandwidth tests a latency probe is sent every 400 ms (every second on links under 2 Mbps, so the probes themselves don't take a noticeable share of a slow connection).

The increase from idle to loaded latency is labelled low (under 30 ms), moderate (30–100 ms), high (100–300 ms) or severe (300 ms or more). These categories are our own.

How packet loss is measured — and when it isn't

Packet loss is measured by sending 1,000 numbered messages over an unreliable WebRTC data channel relayed through a TURN server and counting how many arrive. If the selected server has no relay, the result says “Packet loss measurement unavailable”.

HTTP runs over TCP or QUIC, which silently resend lost packets, so no HTTP-based test can see packet loss. Showing 0% in that situation would be invented data, so we don't. Messages are only sent while the browser's own send buffer is not backed up, so local queuing is not counted as network loss.

How the test server is selected

We choose by measured network performance, not by distance on a map: a nearby server behind a poor route loses to a farther server with a better path.

• Each server gets a warm-up request and four latency probes, all servers in parallel.
• Score = median latency × (1 + 2 × failure rate) × (1 + half of this browser's past failure rate with that server) ÷ a small capacity factor (a server with three times the capacity gains about 5%). Lowest score wins.
• You can pick a server manually with Change server; the list shows each server's live latency.
• The current network includes Cloudflare's global edge, where the physical location serving you (for example a city code such as KHI) is reported after connecting and shown on the result. Dedicated SpeedTester nodes are added to the list only once they are actually running; planned priority locations are Islamabad/Rawalpindi, Lahore, Karachi, Peshawar and Quetta, followed by other Asian hubs.

Where the network information comes from

We never ask for GPS or precise location.

Connection quality thresholds

Each activity's grade is the lowest grade among the metrics it depends on, and the result names the limiting metric. Missing measurements give “Not measured”, not a guess.

Sources: Netflix Help Center speed recommendations (5 Mbps for 1080p, 15 Mbps for 4K); YouTube (about 20 Mbps for 4K); Zoom bandwidth requirements (3.8 Mbps up / 3.0 Mbps down for 1080p group video); Microsoft Teams network guidance (latency under 100 ms, jitter under 30 ms, packet loss under 1%); NVIDIA GeForce NOW (25 Mbps for 1080p60, 45 Mbps for 4K). Gaming latency limits are common industry guidance and our own judgement.

Validation

We check the engine against links with known limits using Chromium's network throttling. Results from the run on 24 September 2026 (local test node):

On the slowest links the emulator itself loses some throughput when a latency probe is in flight, so part of that gap belongs to the emulator rather than to the method. Real-world validation against dedicated servers continues as nodes come online.

Why different speed tests give different results

• Different servers and routes. Each service tests to its own servers; your ISP may route to them differently.
• Different methods. Some report peaks or percentiles, others averages; some use one connection, others many.
• Time and load. Evening congestion, other devices and background updates change results minute to minute.
• Wi-Fi. Signal strength and interference often matter more than the plan.
• Device and browser. Old phones and busy CPUs can limit very high speeds; tests stop if the tab goes to the background.
• ISP-hosted servers. Servers inside an ISP's own network can show higher speeds than you get to the wider internet.

Known limitations

• Browsers cannot send ICMP, so “ping” here is an HTTP round trip — typically a few milliseconds higher than a command-line ping.
• Above roughly 1–2 Gbps, the device and browser may become the bottleneck.
• Packet loss is available only on servers with a WebRTC relay.
• Our analytics and ads load only after the page has settled and never while a test is running, but other apps on your device can still affect results.

Questions or a measurement that looks wrong? Contact us with the Test ID shown on your result. See also our privacy policy.