How we measure and score your connection
Every number on this site comes from transfers between your browser and our own server, and every rating threshold is taken from a published requirement rather than invented. This page documents both, so you can check our work or reproduce it yourself.
What the test measures
A run takes roughly 30 seconds and proceeds in four stages:
- Unloaded latency and jitter. Twenty small requests are timed while the connection is otherwise quiet. We report the median round-trip time, and jitter as the mean absolute difference between consecutive samples.
- Request loss. Forty further small requests are issued and failures counted. This is an HTTP-level estimate, not true IP packet loss — see the caveat below.
- Download. Transfers at 100 kB, 1 MB and 8 MB, repeated several times each. Throughput is timed from the first byte received, so connection setup is excluded.
- Upload. The same approach in reverse, at 100 kB, 1 MB and 4 MB.
Throughout the download and upload stages we keep issuing latency probes in the background. Those samples are your loaded latency — how the connection behaves while it is actually busy, which is when problems occur.
How the headline figures are derived
The Download and Upload numbers are the 90th percentile of the largest transfer size that completed. Small transfers are dominated by latency rather than bandwidth, so using the largest size gives a truer picture of capacity; taking the 90th percentile rather than the maximum discards one-off outliers without punishing a connection for a single slow sample.
Measured throughput is multiplied by 1.06 to compensate for HTTP, TCP and IP framing, which is transferred over the wire but does not appear in the payload byte count.
Stability is 100 minus the coefficient of variation of all download samples, clamped to 0–100. A connection that delivers the same speed on every transfer scores near 100; one that swings wildly scores low even if its peak is high.
Latency under load, and why it matters
The gap between unloaded and loaded latency is bufferbloat: routers and modems queue packets they cannot forward fast enough, and everything interactive waits behind that queue. It is why a video call breaks up the moment someone starts a large upload, even on a fast plan.
Our latency thresholds derive from ITU-T Recommendation G.114, which sets one-way transmission time guidance: below 150 ms most applications are essentially unaffected; 150–400 ms is usable if the impact is understood; above 400 ms is unacceptable for general network planning. Because we measure round-trip time rather than one-way, we apply those figures doubled — a 300 ms round trip corresponds to G.114's 150 ms one-way guidance. G.114 also notes that highly interactive tasks are affected at much lower delays, which is why our gaming thresholds are considerably stricter.
Where the quality-score thresholds come from
Video streaming
Based on Netflix's published connection-speed recommendations: 3 Mbps or higher for HD (720p), 5 Mbps or higher for Full HD (1080p), and 15 Mbps or higher for Ultra HD (4K).
| Rating | Requirement |
|---|---|
| Great | 15 Mbps or more, with stable throughput — meets Netflix's 4K recommendation |
| Good | 5 Mbps or more — meets the 1080p recommendation |
| Average | 3 Mbps or more — meets the 720p HD recommendation only |
| Poor | 1–3 Mbps — below the HD recommendation |
| Bad | Under 1 Mbps |
Video chatting
Based on Zoom's published bandwidth requirements for group meetings: 1 Mbps upstream for 360p high-quality video, 2.6 Mbps for 720p, and 3.8 Mbps for 1080p. Because calls are two-way and interactive, jitter and loaded latency are weighted alongside upload throughput.
| Rating | Requirement |
|---|---|
| Great | 3.8 Mbps upload (Zoom 1080p), jitter under 15 ms, loaded latency under 150 ms |
| Good | 2.6 Mbps upload (Zoom 720p), jitter under 30 ms |
| Average | 1 Mbps upload — Zoom 360p group video only |
| Poor | 0.6–1 Mbps — below Zoom's group-video requirement |
| Bad | Under 0.6 Mbps upload |
Online gaming
Competitive gaming is bound by latency and its variability, not bandwidth. There is no single published standard equivalent to Netflix's or Zoom's tables, so these thresholds derive from G.114's observation that highly interactive tasks degrade well below the general 150 ms one-way limit, combined with the round-trip budgets that game networking engineers commonly design against. We state that openly rather than implying a standard exists where it does not.
| Rating | Requirement |
|---|---|
| Great | Unloaded latency under 30 ms, jitter under 10 ms, loaded latency under 100 ms |
| Good | Under 60 ms, jitter under 20 ms, loaded latency under 150 ms |
| Average | Under 100 ms, jitter under 40 ms, loaded latency under 300 ms |
| Poor | Above those figures but within G.114's usable range |
| Bad | Unloaded latency at or above 300 ms round trip, or loaded latency at or above 800 ms |
Known limitations
- Request loss is not packet loss. True packet loss is measured at the IP layer. A browser cannot see that, so we count failed HTTP requests instead. It will detect a badly broken connection but will read 0% on a link with mild loss that TCP silently retransmits. We label it "request loss" rather than "packet loss" for that reason.
- One server, one location. Every test runs against our server, so your result reflects the path between you and it. A test against a nearer server will usually show lower latency. Results are best compared against your own previous runs on this same test.
- Your device and Wi-Fi are part of the measurement. An old laptop, a distant access point or a congested channel will cap the result below what your line can deliver. Testing over Ethernet isolates the connection itself.
- Browser limits apply. Transfers run through the browser's normal HTTP stack and are subject to its connection limits and scheduling, which is also what real websites experience.
What we store
Test results are not saved and are not tied to you. IP addresses are used transiently to run the test and to look up your network name and city for display; the geographic cache stores only a coarsened prefix, never a full address. See the privacy policy for the complete picture.
Ready to see where your connection stands?