The measurement sequence
- Server selection. The test probes each available server several times and picks the one with the lowest median response time. A closer server gives a more accurate reading of your line.
- Idle latency. After discarding warm-up probes, 30 sequential probes measure the round trip when your line is quiet. Timing uses the browser's Resource Timing data where available, which excludes connection set-up and script scheduling delay. We report the median, so one slow probe cannot skew the result.
- Download. Several parallel streams of random data are downloaded for about 10 seconds. Random data cannot be compressed by anything on the path, so it cannot inflate the result. More streams are added automatically on fast links.
- Upload. The same idea in reverse, with request sizes that grow while the link keeps up, capped to stay within server limits.
- Loaded latency. While each transfer runs, latency probes continue. The first second is ignored because the transfer is still ramping up. The gap between idle and loaded latency shows how your connection copes with heavy use (often called bufferbloat).
- Jitter, loss and stability. Computed from the samples already collected. Jitter is the average change between consecutive idle probes, excluding the largest tenth of changes so a single server hiccup can't dominate. Loss is the share of idle probes that failed. A probe that times out while your connection is saturated is counted as extreme delay in loaded latency, not as loss, because a busy line can delay a probe without dropping a packet. Stability comes from how much throughput varied second to second.
How throughput is calculated
Bytes received (or sent) are counted in 250 ms intervals. TCP starts slowly, so the first part of each phase is discarded (20 percent of the phase, up to 2 seconds). Intervals with no data count against the average, so a stall can't be hidden. For uploads, bytes are counted only when the server confirms it received a whole request, not when the browser says it has sent it: browsers report upload progress as data enters local buffers, which on a slow line can run tens of megabytes ahead of what has really been delivered. The reported speed is the data moved in the remaining stable window divided by that window's length. The interval series is kept so the spread and steadiness of your speed can be shown, not just an average. A byte cap per phase limits data use on very fast connections.
The WiFi Ping Score
The score runs from 0 to 100 and combines four categories. Each metric is converted to a 0 to 100 sub-score with a curve (throughput on a logarithmic scale, because going from 5 to 50 Mbps matters far more than 500 to 1,000). If a metric could not be measured it is left out and the remaining weights are rescaled, never silently treated as perfect.
| Category | Weight | Built from |
|---|---|---|
| Speed | 30% | download (100%) |
| Upload Performance | 15% | upload (100%) |
| Responsiveness | 30% | idleLatency (45%), loadedLatencyIncrease (55%) |
| Stability | 25% | jitter (35%), loss (35%), throughputCv (30%) |
These weights are an initial heuristic, not a scientifically calibrated model. The scoring version (2026.09-heuristic.1) is saved with every result so past tests can be re-scored when the weights are refined using real-world data. The score never replaces the raw measurements, which are always available.
Real-world ratings and diagnosis
Activity ratings (gaming, streaming, video calls and so on) compare your measurements with the typical requirements of those activities. They are guidance, not guarantees. The diagnosis engine applies simple, transparent rules, for example flagging when latency rises more than 60 ms under load, or when download is more than 10 times upload. Every finding separates what was observed from what might explain it, and none is presented as a confirmed cause.
What a browser can and cannot measure
| Measured by WiFi Ping | Not available to a website |
|---|---|
| Download and upload throughput | Wi-Fi network name (SSID) |
| Round-trip latency, idle and under load | Wi-Fi signal strength, channel and band |
| Jitter | Router make and model |
| Failed latency probes (a loss indicator) | True packet loss, which browsers cannot observe |
| Protocol used, IP version, browser and device type | Other devices on your network |
A future native app could provide the second column. Until then, WiFi Ping does not display or guess those values.
Limitations, stated plainly
- Distance to the server. A far server lowers measured speed and raises latency. When the nearest server is far, results include a note.
- Very fast connections. Above roughly 1 Gbps, browser and shared-server limits can understate your real capacity.
- Your device and network. An old phone, a busy computer, VPNs, and other devices on your network all reduce results. Testing with Ethernet and other devices paused shows your line at its best.
- Providers. Some providers route traffic to test servers differently from other traffic. Compare results over time rather than trusting one number.
- Single tests are snapshots. Save several tests at different times to see the real pattern.
Questions about the method? Read the privacy details or the guide to a good internet speed.