Internet speed tests and what the numbers actually mean

When a video call stutters or a download crawls, the first instinct is to run a speed test. The Internet Speed Test measures your connection straight from the browser — no app to install, no server of ours in the middle — but the four numbers it returns only help if you know what each one is actually telling you.

The four numbers

• Download throughput — how fast data moves from the internet to your device. This is the headline number people quote, and the one most affected by the path between you and the test endpoint.
• Upload throughput — the reverse direction. It matters for video calls, cloud backups and any time you push large files. Home connections are often asymmetric: a 100 Mbps download plan may pair with a 10 Mbps upload.
• Latency (ping) — the round-trip time for a single small request, in milliseconds. It is what makes a remote desktop feel snappy or laggy, and it is independent of throughput.
• Jitter — the variation in latency across repeated requests. A stable 40 ms ping is far better for real-time use than a ping that bounces between 20 and 80 ms.

Throughput is a capacity; latency and jitter are about consistency. A connection can have huge throughput and still feel broken for a call if jitter is high.

How a browser test measures it

There is no special hardware involved. The test downloads a fixed-size payload over HTTPS, times it, and converts bytes-per-second to megabits-per-second. Upload is the mirror image — it pushes a payload to an endpoint and times the return. Latency comes from many small fetches; jitter is the standard deviation of those latencies.

throughput (Mbps) = (bytes * 8) / seconds / 1_000_000

Because it runs over HTTPS to a nearby edge, the result reflects the real path your traffic takes — including your Wi-Fi, your router, and your provider's link. That is the point: the number you see is the number your browser actually experiences, not a theoretical line rate.

What skews a result

• Other traffic on the connection. A background upload or a family member streaming will eat throughput. Close everything before testing.
• Wi-Fi vs ethernet. A congested 2.4 GHz band can halve real throughput even when the line rate is fine. Plug in a cable to isolate the link from the airwaves.
• Distance to the test endpoint. Throughput falls with latency because TCP windows take time to open. The same connection will measure higher against a nearby edge than a distant one.
• Time of day. Evening congestion on shared infrastructure is real. Test at the hour you care about.

Reading the numbers together

A fast download with poor latency points to a throughput-rich but routed-poorly path — common on satellite or long-distance links. Good latency with low download suggests the bottleneck is your provider's capacity, not the route. High jitter with normal average latency usually means a flaky wireless hop.

Pair the result with the What Is My IP tool to confirm which network and exit node you are actually testing from, and the IP Geolocation lookup to see where that exit node sits. Together they explain not just how fast the connection is, but where its limits come from.

The honest takeaway

A speed test is a snapshot, not a verdict. Run it a few times, under the conditions you actually care about, and compare the four numbers rather than fixating on download. That is what turns a single megabits-per-second figure into something you can actually act on.