Trust & legal
How this test works, what it measures, and the practical limits of any browser-based speed test.
Written and reviewed by Subham Sharma · Last reviewed: August 24, 2026
How the test runs
Live Internet Speed uses the open-source @cloudflare/speedtest package (version 1.13.1 at the time of writing), published under Cloudflare's own npm namespace and used to power speed.cloudflare.comitself. When you press "Start Speed Test," your browser opens a series of requests directly to Cloudflare's network : not to our own servers. We never operate or proxy the measurement traffic ourselves. The test runs in several phases: idle latency, a download ramp using progressively larger payloads, and an upload ramp, with latency also sampled while download and upload are active.
What each measurement means
- Download / upload speed (Mbps): throughput measured across multiple requests of increasing size, using the 90th percentile of samples that ran long enough to be reliable : not the median, which the underlying engine reserves for latency (see below).
- Idle latency (ping): round-trip time to Cloudflare when the connection isn't otherwise busy, taken at the median of several samples.
- Jitter: how much idle latency varies between individual samples.
- Loaded latency: latency measured while download or upload traffic is active, which reveals how much the connection slows down under load (sometimes called bufferbloat).
How we interpret results
Ratings, use-case assessments, and recommendations are produced by deterministic rules in our own code : not a generative AI model : using threshold ranges we maintain and review. These ranges are practical guidance based on typical activity requirements, not universal physical constants, and we adjust them as real-world usage patterns change.
| Metric | Guidance ranges |
|---|---|
| Download | Below 5 Mbps limited · 5–25 basic · 25–100 good · 100–500 very good · above 500 excellent |
| Upload | Below 2 Mbps limited · 2–10 basic · 10–50 good · above 50 excellent |
| Idle latency | Below 20 ms excellent · 20–50 good · 50–100 acceptable · above 100 poor for real-time use |
| Jitter | Below 5 ms excellent · 5–15 good · 15–30 noticeable · above 30 unstable |
| Loaded latency increase | Below 20 ms excellent · 20–50 good · 50–100 noticeable · above 100 likely bufferbloat |
We deliberately avoid over-crediting raw bandwidth: a very fast connection with high latency or jitter under load will not automatically receive an "excellent" rating, because that combination causes real, noticeable problems in games and calls even though a download number alone looks great.
Sources: the download/upload floor reflects the FCC's Household Broadband Guide and Broadband Speed Guide. The jitter and loaded-latency bands are this site's own practical synthesis for real-time use cases (gaming, calls) rather than figures drawn from a single published standard.
Why results differ from other speed tests
Every speed test measures performance between your device and that provider's own network of servers. Server location, network routing (peering, transit paths), TCP/QUIC implementation details, browser behavior, and the exact testing methodology (payload sizes, sample counts, percentile used) all affect the number you see. A difference between this test and Speedtest.net, Fast.com, or your ISP's own tool does not mean either result is "wrong" : it reflects a different measurement path.
One specific, common source of a lower download number here: the @cloudflare/speedtest engine measures download and upload using a single connection at a time, sending each request only after the previous one finishes (verified against the engine's own source for the version this site runs). Different speed tests use different concurrency and sampling methods : some open several parallel connections at once to saturate the link, which can read higher than a single-connection result on the same network, since one TCP connection takes time to ramp up its congestion window. This is a deliberate design choice in this engine, not a bug in this site, and it also tends to make a full test take longer than a fixed-length multi-connection test. A difference can also come from the measured server itself : some providers host a test server on your own ISP's local network, which will naturally show lower latency than any test reaching an external provider's edge, Cloudflare's included.
What we don't measure yet
This version does not measure packet loss, so no packet-loss value is reported. Reliable packet-loss measurement needs a WebRTC TURN relay with securely issued, per-session credentials, and the underlying engine's public TURN server for this is documented as deprecated, so we chose not to ship an unreliable measurement rather than build against a server that's being discontinued. We may add it later if a secure credential flow becomes available : see the "detected issues" section of your result for other signals of connection instability in the meantime.
Accuracy
Because this site uses the same open-source engine as speed.cloudflare.com with its default configuration, a test run here and one run there should read very similarly on the same connection at the same time. We don't expect : or claim : identical readings from Speedtest.net, Fast.com, or M-Lab; see the explanation above for why.
Live Internet Speed is an independent service and is not affiliated with, sponsored by, or endorsed by Cloudflare, Inc. Cloudflare is a trademark of Cloudflare, Inc.