Real measurements. Clear limits.

The route we test

We measure data between this browser and the configured HTTPS endpoint. The initial endpoint is hosted with the application in Singapore. This is a single route, not a worldwide network of measurement servers. Shared hosting, routing distance, and server load can become bottlenecks before your own connection does.

Download and upload

We transfer cache-busted binary data with no-store headers. Parallel requests start with small payloads and adapt within configured limits. Download counts bytes read from response streams. Upload counts only complete payloads acknowledged by the receiving endpoint. Mbps equals transferred bytes × 8 ÷ elapsed seconds ÷ 1,000,000.

Each transfer phase uses its actual wall-clock duration, including request overhead and concurrent latency probes. This conservative application-throughput estimate is especially sensitive to HTTP overhead on fast connections. Payloads are random binary data; upload payloads are read and discarded, never saved as files. Limits can stop a phase before its chosen duration. An interrupted test shows an error rather than a fabricated result.

Latency, jitter, and loaded latency

After a warm-up request, we time eight sequential small HTTP requests using the browser’s monotonic performance clock. The displayed idle latency is their arithmetic mean. The 95th percentile is the nearest-rank value in the sorted samples. Jitter is the arithmetic mean of the absolute differences between each successive pair of idle round trips.

Up to four additional probes run during each transfer phase. Their mean is loaded HTTP latency. It includes browser scheduling, connection setup when needed, TLS, server processing, and network travel. These are HTTP round trips, not ICMP ping measurements. Small samples should be treated as indicators.

Why packet loss is unavailable

Ordinary browser Fetch requests cannot reliably separate network packet loss from retransmissions, server errors, and application failures. We show packet loss as unavailable. Failed requests are errors, not a claimed packet-loss percentage.

Our connection score

The score is a site-specific heuristic, not an industry certification. Download contributes 40 points at 100 Mbps, 30 at 25, 20 at 10, otherwise 10. Upload contributes 20 points at 10 Mbps, 12 at 3, otherwise 5. Latency contributes 25 points below 40 ms, 15 below 100, otherwise 5. Jitter contributes 15 points below 10 ms, 8 below 30, otherwise 0. Scores of 85 or more are Excellent, 65–84 Good, 40–64 Fair, and lower scores Need attention.

Activity labels

Our indicative download thresholds are 3 Mbps for browsing, 5 for HD streaming, 25 for 4K, and 100 for large downloads. Video calls use at least 3 Mbps in both directions and latency below 150 ms. Our gaming indicator uses at least 10 Mbps download, latency below 60 ms, and jitter below 20 ms. These are editorial comparison thresholds, not guarantees or claims about any specific service. Multiple people and devices need shared capacity, and service requirements vary.

What changes a result

Router placement, congestion, other devices, WiFi interference, a VPN, browser throttling, server capacity, and distance can all affect the result. The connection panel shows your server-observed public IP and looks up its registered network owner and ASN in a local IPtoASN database. No visitor IP is sent to a third-party lookup service. A VPN or proxy can make this the exit network rather than your home ISP. We cannot identify your router model, signal strength, physical location, or precise access technology from an ordinary browser; a connection type is shown only if the browser explicitly exposes it.

Privacy and retention

Recent results stay in browser storage. The server keeps short-lived anonymous test summaries to operate the service and calculate aggregate statistics. A share link is created only when requested and expires automatically. Shared values are browser-reported and not independently certified. Read the privacy notice.