Speed Test & Network Lab

Measure your internet performance and get personalized insights

—

Mbps

Download

—

Mbps

Upload

—

Latency

—

Jitter

HOW IT WORKS

Speed testing process

SERVER SELECT

Choose test server

DOWNLOAD TEST

Measure download speed

UPLOAD TEST

Measure upload speed

ANALYSIS

Calculate indices

Why Mbps Is the Wrong Number for Internet Speed

A modern internet connection is rated in megabits per second. Marketing focuses on the number. Reviews compare ISPs by the number. Speedtest websites display the number in giant pixel-counted text. The number turns out to be one of about five things that decide whether your connection feels good or bad, and it's not the most important one most of the time. A 100 Mbps connection with 80ms of jitter is worse for video calls than a 25 Mbps connection with 2ms of jitter. A 1 Gbps connection with bufferbloat above 200ms turns every Slack call into a stuttering mess the moment someone in the household downloads a movie. A 200 Mbps connection routed through a peering link three datacenters away feels slower than a 50 Mbps connection on a well-routed network. The bandwidth number is the cover; the rest of the story sits behind it. A serious speed test measures four orthogonal axes: raw bandwidth (Speed), consistency over time (Stability), connection-type detection and routing sanity (Trust), and ISP-vs-peer comparison (Fairness). The first axis is what every other test reports. The other three are where the actionable answer lives. Sections below: which numbers actually predict experience, what bufferbloat and loaded latency reveal that ping doesn't, and why a 100 Mbps connection feels different across services even on the same provider.

Bandwidth Is Half the Story

Four numbers control how an internet connection feels. Bandwidth (Mbps). The headline number. Caps how fast a single large transfer can complete. Affects software updates, video downloads, and file backups. Doesn't directly affect anything that involves small frequent packets. Latency (ms). Round-trip time to a target. Affects everything interactive: gaming, video calls, voice, SSH, terminal apps, web pages with many small requests. A page that loads 60 separate resources at 50ms latency takes 3 seconds just on round trips. The same page at 10ms latency takes 600ms. Bandwidth is irrelevant to that calculation until each individual resource is being throttled. Jitter (ms variation). The standard deviation of latency across multiple samples. Affects voice and video calls catastrophically. A 50ms average latency with 2ms jitter sounds clear. A 50ms average latency with 30ms jitter has audible glitches. Voice codecs (Opus, AAC-LD) tolerate jitter up to a buffer; past the buffer they drop frames or insert silence. A speed test that reports only 'average ping' hides this. Bufferbloat (loaded latency in ms). The increase in latency when the connection is under load. Cheap home routers buffer outgoing packets aggressively. When the upload pipe fills, latency to anything else can spike from 30ms to 500ms. Video calls turn into delayed-by-half-a-second slideshows. Online games timeout. The user thinks 'why is my internet bad' and the speed test, run during a quiet moment, reports 100 Mbps and 30ms ping, all green. The diagnostic missed the entire failure mode. Loaded latency is the cure. Measure ping while the bandwidth test is running. The difference between idle ping and loaded ping is the bufferbloat number. Connections under 50ms increase are fine. 50-200ms is meaningful for real-time applications. Above 200ms is broken in a way the user feels even if they don't have the vocabulary for it. Same way a thirty-second delay between asking a question and the response makes a phone call awkward even if every word is clear: the technology works, but the rhythm of conversation is gone. These four axes interact in non-obvious ways. A fiber connection with 1 Gbps down and 50 Mbps up can still bufferbloat the upload during a one-person Zoom call because the 50 Mbps upload fills first. The user sees the symptom on the download side (latency spikes during incoming video) but the cause is on the upload. Diagnosing this requires testing both directions under load.

Trust and Fairness: The Numbers That Aren't Numbers

Two indices that bandwidth-focused tests don't surface. Trust scores connection-type detection and routing sanity. Mobile carrier? Residential ISP? Datacenter? VPN? Each of those has different expected characteristics. A 'residential connection' returning 800 Mbps to a US-coast datacenter from a European IP is suspicious. That's datacenter performance, not residential. The result is still useful (you have a fast pipe) but the framing of 'how does my home internet perform' has been quietly replaced by 'how does my datacenter VPN perform'. Trust flags this so the user knows what they're actually measuring. Same logic as grading a runner's mile time when they were on a moving walkway: the number is honest, the context isn't. Path sanity is part of Trust. Latency to nearby cities should be a function of physical distance. London to Paris fiber latency is around 6ms. London to Frankfurt is around 12ms. London to Madrid via direct routes is around 25ms. When the test sees London-to-Madrid at 80ms, something is routed wrong: traffic going through a US peering exchange, or a misconfigured BGP path. The connection is technically fine; the routing is poor. Trust catches this where pure speed tests can't. Fairness compares your performance to expected values for your ISP and region. A 200 Mbps connection on Comcast in Boston averaging 180 Mbps is normal. Same plan in the same city averaging 60 Mbps is throttled, congested, or oversold. The Fairness index needs a reference dataset (ours comes from anonymised tests aggregated over the past 90 days) and computes the user's percentile within their cohort. The contextual framing matters more than the raw number. 'Your connection runs at 180 Mbps' sounds great until you learn that 95% of Comcast Boston customers on the same plan are at 200 Mbps. Either you're being throttled, your modem is undersized, or your line has signal issues. The diagnosis requires the comparison group; the speed test alone doesn't have it.

Why 100 Mbps Feels Different Across Services

The same connection performs differently depending on what you connect to. CDN coverage is the first variable. YouTube, Netflix, Apple, and Google operate dedicated edge servers inside most major ISP networks. Traffic to them never leaves the ISP's network and lands at sub-10ms latency. Twitch, by contrast, runs almost entirely from AWS us-east-1; European users hit it at 100-150ms regardless of bandwidth. Same connection, very different experience. Same logic as living next door to one supermarket and forty miles from another: the items might be identical, the trip is what differs. ISP peering is the second. ISPs interconnect via Internet Exchange Points. The agreements between ISP A and ISP B determine how much bandwidth flows between them. When the agreement is undersized, peak-hour congestion at the exchange degrades performance. Cogent and Hurricane Electric had a multi-year peering dispute in the early 2010s that produced predictable evening slowdowns for any traffic between their networks. Modern equivalents exist; users see them as 'streaming is bad in the evening but fine at noon'. Last-mile congestion is the third. Cable ISPs share bandwidth across neighborhood nodes. When too many subscribers stream simultaneously, the node's upstream link saturates. The user sees Mbps drop from advertised rates to whatever the node-level division supports. Speedtest.net usually picks a server inside the ISP's network for measurements, which means the test passes even when the ISP's upstream is the actual bottleneck. Middlebox interference is the fourth. Some ISPs throttle specific traffic classes (BitTorrent, Usenet, VPN protocols) or specific destinations during peak hours. Comcast's well-documented throttling of BitTorrent in 2007 was followed by similar moves by Cox, AT&T, and others; the practice quieted under net-neutrality scrutiny and came back in modified forms after rules were rolled back in 2018. The traffic looks slow only when it's the throttled class. A speed test using HTTP to a non-throttled destination passes the test while the user's actual workload still suffers. The diagnostic implications: a single number called 'speed' doesn't capture any of this. A useful speed test reports bandwidth in both directions, idle and loaded latency, jitter, the destination it tested against, and a routing-sanity assessment. Five numbers, surfaced honestly, tell the story that one number called 'Mbps' deliberately hides. The WHOX speed test runs the four-axis measurement (Speed, Stability, Trust, Fairness), tests against geographically-distributed servers, computes loaded latency and jitter under both download and upload load, and surfaces the routing-sanity check separately so the user can distinguish between 'connection is slow' and 'connection is fine, this destination is poorly routed'. Same data the ISP's own monitoring would generate, packaged for the customer who wants to know what their connection is actually doing.

FREQUENTLY ASKED QUESTIONS

Why are the indices different from raw speed?

Raw speed (Mbps) only tells part of the story. The Speed Index accounts for both download and upload with appropriate weighting. Stability Index measures connection consistency - a 100 Mbps connection with high jitter may perform worse than a stable 50 Mbps one. Trust Index reflects network type detection, and Fairness compares your performance to expected values for your ISP.

What makes this different from Speedtest or Fast.com?

We focus on actionable insights rather than just numbers. Instead of just showing '100 Mbps', we tell you 'Excellent for gaming, but high jitter may affect video calls'. We also integrate WHOX network detection to show if you're on VPN, datacenter, or residential connection, which affects how services treat your traffic.

Why does the test stop before maximum duration?

Our adaptive algorithm monitors speed stabilization. Once measurements converge (less than 5% variance between samples), continuing the test won't improve accuracy. This makes tests faster on both slow and fast connections while maintaining precision.

All our tests

Run the full WHOX toolkit from one place: leak checks, fingerprint probes, network diagnostics, reputation lookups, and privacy failure tests.