The test above downloads a few megabytes from this server, uploads a small payload back, and times round-trip probes to estimate the bandwidth and latency of your connection. What it cannot tell you is whether the bottleneck is your Wi-Fi radio, your router, your modem, your ISP, or the network path between this server and you. Below I explain what every number means in practice, what a usable result looks like for streaming, gaming, and video calls, and the diagnostic steps I run when the answer disappoints. I run this against my own home line in Karachi several times a week, and I will share the numbers I actually see.
What this speed test measures (and what it does not)
The test reports four values that together describe the shape of your connection. Download throughput is how many bits per second the server can push to you. Upload throughput is how many bits per second your device can push back. Most consumer broadband plans are asymmetric: a 200 Mbps cable plan often ships with only 20 Mbps upload. Latency (also called ping or RTT) is the time a small packet takes to travel to the server and back, measured in milliseconds. Jitter is the variation in latency between repeated samples, which matters for live audio and video.
A few common confusions I see in support tickets. Mbps stands for megabits per second; MB/s stands for megabytes per second. There are eight bits in a byte, so 100 Mbps is roughly 12.5 MB/s before protocol overhead. ISPs advertise in Mbps because the number is bigger; file managers show MB/s. They are not lying to you when they disagree, they are using different units. A 1 GB game download on a 100 Mbps line should take about 80 to 90 seconds in ideal conditions.
Equally important is what the test does not measure. It does not isolate Wi-Fi quality from wired throughput. It does not predict how your connection will behave at 9 PM on a Friday when half the neighborhood is streaming. It does not measure CDN performance for a specific service, since Netflix, YouTube, and Cloudflare all use different edges that may not match the path between you and this server. And it does not measure packet loss directly. If you need any of those, you need a longer test against a server inside your target network.
How to read your results in plain numbers
Throughput requirements have not changed much in years, despite what speed-test marketing implies. Netflix publishes its minimums at help.netflix.com: 3 Mbps for standard definition, 5 Mbps for 1080p, 15 Mbps for 4K. Zoom recommends 1.5 Mbps up and down for HD video calls per its system requirements. Competitive online gaming barely uses bandwidth at all, often under 1 Mbps, but is extremely sensitive to latency above 60 ms and to any jitter at all.
The table below is what I keep in my head when triaging slow-internet complaints from family and clients. It is conservative; the โrecommendedโ column accounts for a household with multiple devices doing the activity at the same time.
| Activity | Minimum download | Recommended download | Minimum upload |
|---|---|---|---|
| Web browsing, email | 3 Mbps | 25 Mbps | 1 Mbps |
| HD streaming (1080p) | 5 Mbps | 10 Mbps | 1 Mbps |
| 4K streaming | 25 Mbps | 50 Mbps | 1 Mbps |
| Zoom HD video call | 3 Mbps | 6 Mbps | 3.8 Mbps |
| Online gaming (FPS, MOBA) | 3 Mbps | 25 Mbps | 1 Mbps |
| Large file backup / upload | 25 Mbps | 100 Mbps | 50 Mbps |
| 4K live streaming (OBS) | 25 Mbps | 50 Mbps | 20 Mbps |
For latency: under 30 ms is excellent, 30 to 60 ms is good for most activities, 60 to 100 ms is noticeable in competitive gaming and live music collaboration but fine for everything else, and above 150 ms makes video calls feel awkward. Jitter under 10 ms is healthy; jitter above 30 ms produces audible drops in voice calls even when raw bandwidth is high.
Why your speed varies between runs
Refresh this page three times and you will almost certainly get three different numbers. The biggest reasons in roughly the order they bite:
- Wi-Fi versus wired. A Wi-Fi link can absorb 30 to 70 percent of advertised speed depending on how old your router is and how far you sit from it. On a 100 Mbps plan I have measured 94 Mbps wired and only 38 Mbps over a TP-Link Archer C7 from 2019 sitting in the next room. The connection was not broken; the access point was. After replacing it with a Wi-Fi 6 router, the same plan now reports 89 Mbps over 5 GHz. If you have not replaced your router in five years, replace it before blaming the ISP.
- Peak hours. ISPs oversubscribe their lines on the assumption that not everyone is downloading at once. Between 8 PM and 11 PM local time, especially on weekends, you will see slower results because the neighborhood pool is full. Test once in the morning and once at 10 PM to see the spread.
- Device limits. A cheap Android tablet with a 2.4 GHz-only Wi-Fi radio cannot exceed about 50 Mbps even on a gigabit line. The same is true for old laptops with single-stream 802.11n radios.
- Server distance and peering. This test runs against my hosting provider. If that provider has good peering with your ISP, you will see numbers close to your plan ceiling. If it does not, you may see 60 percent of your plan even on a flawless local link. That is why most serious tests let you pick the server.
- Background traffic. Windows Update, macOS Software Update, Google Drive sync, and Time Machine backups all consume bandwidth while running. Pause them and rerun.
- ISP throttling. Some ISPs reduce throughput for specific services (often video or P2P) during congestion. A general speed test usually escapes this, but if Netflix is slow while this test shows your full plan, the throttle is service-specific.
Testing throughput from the command line
A browser test gives you one snapshot. A terminal test, repeated, gives you a distribution. The commands below work on a default install and are what I use when escalating to an ISP.
Windows (PowerShell)
# Time a 100 MB download from Cloudflare and print throughput
$start = Get-Date
Invoke-WebRequest -Uri "https://speed.cloudflare.com/__down?bytes=104857600" -OutFile $null
$elapsed = (Get-Date) - $start
$mbps = (100 * 8) / $elapsed.TotalSeconds
Write-Host "Download: $([math]::Round($mbps, 1)) Mbps over $([math]::Round($elapsed.TotalSeconds, 1))s"
# Ping a known target 20 times for latency stats
Test-Connection -ComputerName 1.1.1.1 -Count 20The first block downloads a 100 MB file from Cloudflare and computes Mbps by hand. Cloudflare's speed endpoint is free to hit and accepts a byte-count parameter. Test-Connection is the modern PowerShell ping; the count and round-trip fields give you both latency and a coarse jitter estimate.
macOS and Linux
# Download with timing breakdown
curl -o /dev/null -w "Speed: %{speed_download} bytes/sec\nTime: %{time_total}s\n" \
https://speed.cloudflare.com/__down?bytes=104857600
# Ping with rich statistics (mtr also shows hop-by-hop)
ping -c 20 1.1.1.1
mtr -r -c 20 1.1.1.1curl -w prints the download speed in bytes per second; multiply by 8 and divide by 1,000,000 to get Mbps. mtr walks the route to a target and shows latency at every hop, which is the single most useful command when latency is high and you want to know where. If a specific hop in the middle of the trace shows 200 ms and the next hop is back to 20 ms, that hop is rate-limiting ICMP, not actually slow.
When the result does not match your plan
If you pay for 200 Mbps and the test shows 80 Mbps, here is the order I work through before calling the ISP. Each step takes a few minutes and rules out a layer.
- Wire it. Connect a laptop directly to the modem with an Ethernet cable, with the router removed from the path entirely. Rerun. If wired matches your plan and wireless does not, the router or the radio is the limit. If wired is also slow, the problem is upstream of your house.
- Reboot the modem. Power-cycle for a full 60 seconds. Cable modems in particular hold onto bad channel assignments until rebooted.
- Test a single device alone. Disconnect every other device on the network. If the result jumps, something else was saturating your link.
- Try a second test against a different server.Cloudflare, fast.com, and Ookla all use different infrastructure. If they all agree, the bottleneck is on your side or your ISP's. If only one is slow, that one probably has poor peering.
- Save the results. Take screenshots with timestamps, ideally at three different times of day. Most ISPs will refuse to act on a single test and most contracts only guarantee a percentage of advertised speed.
- Call with data, not feelings.โI get 80 Mbps wired at 10 AM and 60 Mbps at 9 PM on a 200 Mbps planโ gets a useful response. โThe internet is slowโ gets a router reboot script and a hung-up phone.
Why different speed test sites give different numbers
You can run Cloudflare's test and Ookla's test back to back on the same machine and get answers 30 percent apart. None of them are wrong. They make different methodology choices that produce different numbers, and understanding those choices tells you which one to trust for what.
Server selection. Ookla's speedtest.net picks the lowest-latency server from a global pool that includes many ISP-hosted servers. That often means the test runs inside your own ISP's network, which maximizes throughput but does not reflect what you actually experience reaching the wider internet. Cloudflare's test runs against Cloudflare's anycast network, which is close to most users but is a specific commercial network. fast.com runs against Netflix Open Connect appliances, so it measures the path you actually take to Netflix specifically.
Single-thread versus multi-thread.A single TCP connection on a long-haul link rarely reaches gigabit speeds because of the way TCP's congestion window scales with round-trip time. Multi-stream tests open eight or sixteen parallel connections, which adds up to the true link capacity but does not reflect what a single download like a Steam game install actually achieves.
Payload size and warmup. Some tests transfer 100 MB; some transfer 1 GB. Short tests overweight TCP slow-start and underreport sustained throughput. Long tests are more accurate but harder to run on slow connections.
When numbers disagree, do not pick the one you like. Pick the one that matches what you actually care about. If you want to know whether Netflix will stream cleanly, use fast.com. If you want to know whether your line can do a fast file transfer, use a multi-thread test. If you want a single representative number, use any of them with a server in a region you actually reach.
Frequently asked questions
What is a good internet speed for streaming?
For one 1080p stream, 5 to 10 Mbps is plenty. For one 4K stream, 25 Mbps download is the floor; 50 Mbps gives headroom for a second device on the network. Netflix publishes 15 Mbps as its 4K minimum. Latency does not matter for streaming because video players buffer ahead. Upload speed does not matter unless you are also on a video call.
Why is my Wi-Fi slower than my plan?
Wi-Fi loses to wired Ethernet on almost every link. A 2.4 GHz radio caps around 50 Mbps in practice. A 5 GHz radio on a modern router can deliver 400 to 800 Mbps in the same room, but signal drops sharply through walls. If your router is over five years old, replace it. If the access point is fine, move closer to it or add a mesh node. Wired Ethernet from the laptop to the modem will always be the upper bound.
What is the difference between Mbps and MB/s?
Mbps is megabits per second; MB/s is megabytes per second. There are eight bits in a byte, so 100 Mbps equals roughly 12.5 MB/s before TCP overhead. ISPs quote in Mbps because the number is larger. File transfer windows quote in MB/s because that is how big the file actually is. They describe the same connection in different units.
Why do different speed test sites give me different results?
Each test uses a different server, a different number of parallel connections, and a different payload size. Ookla often hosts servers inside ISPs and shows the highest number. fast.com runs against Netflix infrastructure and shows the speed you will actually get for Netflix. Cloudflare runs against its own anycast network. None are wrong; they answer different questions.
Is my ISP throttling me?
If a general speed test shows full speed but specific services (Netflix, YouTube, BitTorrent) are slow, the ISP is likely throttling those services. Run the test first; if you see your plan ceiling, the throttle is service-specific. Some ISPs also throttle after monthly data caps. A VPN can sometimes bypass service-specific throttling because the ISP cannot see what is inside the encrypted tunnel.
Related tools
Latency and throughput are different problems. If your bandwidth is fine but pages still feel slow, see What Is My Latency for round-trip times to this site. The organization behind your connection is in What Is My ISP. If you suspect Wi-Fi versus cellular handoff is involved, What Is My Network Type shows the connection class your browser reports. And for the public IP that any support ticket will ask for, What Is My IP.
Sources cited above
- Netflix Help Center: recommended internet speeds per video quality
- Zoom system requirements: bandwidth needs for HD video calls
- RFC 6349: Framework for TCP throughput testing
- Cloudflare Speed Test: open endpoint used for download timing
- fast.com: Netflix Open Connect speed measurement
- Ookla Speedtest methodology: multi-thread test architecture