If you've run a speed test in the last decade, you've probably experienced the unsettling feeling of getting three different answers from three different tools at the same time. None of them agree with your ISP's marketing material. None of them quite agree with each other. The number changes if you re-run it five minutes later. And nobody can tell you which one is "the real number."

The answer is that all three numbers are real — they just measure slightly different things. Knowing which is which lets you (a) figure out whether you're getting what you paid for, (b) diagnose actual connection problems, and (c) stop arguing with your ISP's tech support based on numbers that aren't comparing apples to apples.

The five things that change the result

1. Which server you're testing against

This is the single biggest variable. Every speed test connects you to a specific server somewhere and measures bandwidth between you and that server. Different tools pick different servers.

Speedtest.net picks the geographically nearest "Speedtest server" — which is often hosted by your ISP itself inside their network. The path between you and that server never leaves the ISP, which means the ISP can give you their best throughput. They have every incentive to make this number look as good as possible.

Cloudflare's speed test (and ours, which uses the same Cloudflare edge infrastructure) connects to a Cloudflare data center. That's a real-world destination — most of the internet's traffic eventually flows through a Cloudflare-adjacent network — so the number you get is closer to "real-world bandwidth to popular sites." It might be lower than the ISP's number because it includes the path between the ISP and Cloudflare.

Fast.com (Netflix's speed test) connects to Netflix's CDN. The number reflects what your Netflix streaming experience would be. Similar logic.

Your ISP's own tool connects to an ISP-controlled server on their own backbone. Best-case numbers. Marketing material.

None of these are wrong. They're just different questions. "How fast can I download from a server my ISP runs?" vs "How fast can I download from Cloudflare?" are not the same question, and there's no reason the answers should match.

2. Time of day

ISPs sell bandwidth at the connection level (the link between your house and their nearest aggregation router) but the actual throughput you get depends on contention with everyone else sharing the path between that aggregator and the destination.

Your house has a guaranteed 300 Mbps to your neighborhood DSLAM or CMTS. But beyond that, you're sharing capacity. The link from your aggregator to the ISP's backbone is shared with thousands of other customers. The peering link from the ISP to Cloudflare/Netflix/AWS is shared with millions.

At 3am on a Tuesday, no one else is competing. You get the full bandwidth. At 8pm on a Sunday during a Netflix premiere, half your neighborhood is streaming 4K. The shared upstream link is saturated. Your individual connection speed depends on whatever capacity is left.

This is the famous "peak hours slowdown." A connection that runs at 300 Mbps off-hours can drop to 80 Mbps at 8pm. The ISP didn't actually do anything — your local last-mile is still fine. The contention is upstream of you.

The honest test: run a speed test at 3am and again at 8pm. If they match, your provider has plenty of headroom. If 8pm is half the 3am number, you're seeing congestion-pricing reality.

3. WiFi vs Ethernet

This trips up more people than any other factor. WiFi is a shared-medium protocol with overhead, interference, and rate adaptation. A 300 Mbps internet connection can deliver maybe 200 Mbps over a typical 5GHz WiFi link in real-world conditions. Walls, neighbors' WiFi, and microwave interference make this worse.

If you're testing on a phone over WiFi, you might be measuring your WiFi, not your internet. Plug a laptop directly into the router with an ethernet cable, then re-run the speed test. If ethernet shows 290 Mbps and WiFi shows 90 Mbps, the bottleneck is your WiFi, not your ISP. Fix: better router placement, switching to 5GHz/6GHz, getting an access point closer to where you actually sit.

2.4GHz WiFi tops out around 60-80 Mbps in practice regardless of the radio's theoretical max because that band is congested everywhere. 5GHz is significantly faster. 6GHz (WiFi 6E / WiFi 7) is faster still and almost no one is using it yet, so it's clean.

4. TCP overhead and protocol

Your ISP sells "raw bandwidth at the link layer" — the number of bits per second on the physical wire to your house. But applications use TCP (or QUIC), which adds protocol overhead.

TCP includes headers (~5-10% overhead on small packets), acknowledgments going back upstream, and a slow-start algorithm that takes a few hundred milliseconds to ramp up to full throughput. For a short download (1-2 seconds), TCP might never reach the link's capacity before the file finishes. A speed test that uses a 1MB sample will report a lower number than one using a 50MB sample for exactly this reason.

Modern speed tests use either large-enough samples (10MB+) or multiple parallel TCP connections to saturate the link. Older speed tests sometimes don't. If your speed test reports 50 Mbps on a connection that's actually 300 Mbps, the test might be too small a sample.

5. What the ISP is doing with your traffic (the controversial one)

Some ISPs prioritize speed-test traffic. They don't have to advertise this — they can simply configure their network so traffic going to speedtest.net's servers gets QoS preference. Their internal speedtest server gets even more preference. Meanwhile, your actual Netflix traffic might be deprioritized during peak hours.

This is sometimes called "speed-test gaming." It's hard to prove conclusively because the ISP can always claim coincidence, but Measurement Lab and university researchers have documented multiple ISPs doing it.

The defense: test against multiple endpoints. If Speedtest.net shows 280 Mbps but a download from a small VPS in another country shows 60 Mbps, the small VPS number is probably closer to your real internet experience. A test against Cloudflare or Netflix should fall somewhere in between.

How to actually benchmark your connection

If you want a defensible number — say, you're considering switching ISPs or building a case for a refund — here's a methodology:

Use ethernet. Plug a computer directly into the router with a cable. Disable WiFi temporarily. This removes WiFi as a variable.
Test at 3am or before 8am. Off-peak hours show what your connection is capable of with no contention.
Test at 8pm on a weekend. Peak hours show what you actually get under load. The gap between off-peak and peak is your contention reality.
Test against multiple endpoints. Run Speedtest.net (probably ISP-favorable), Cloudflare/Fast.com (real-world destination), and your ISP's own tool (most favorable). The Cloudflare number is closest to your actual internet experience.
Take 5 measurements per test. Pick the median, not the best. Single tests are noisy; the median of 5 is stable.
Test the upload too. Most plans are asymmetric — 300/30, 1Gbps/30Mbps. Upload speed matters for video calls, screen sharing, and uploading files. If your ISP advertises symmetric and you're getting 1/10 ratios, that's worth a complaint.

Document all of it. Date, time, test, server, result. If you ever need to argue with the ISP, three weeks of consistent data is more persuasive than one outlier measurement.

What "300 Mbps" actually means in your contract

Read the fine print of your ISP plan. The term you signed up for is almost always "up to 300 Mbps." That "up to" is doing a lot of work. It means:

The connection's theoretical maximum is 300 Mbps
The link layer (DOCSIS, fiber, DSL) is provisioned for that rate
You may or may not actually get that rate at any given moment depending on conditions outside the ISP's "best effort" service-level promise

What it doesn't mean:

That every speed test will show 300 Mbps
That every server you connect to will deliver 300 Mbps of throughput
That your home network is capable of consuming 300 Mbps
That you'll get 300 Mbps at peak hours

Some regulatory regimes (UK Ofcom, parts of the EU) require ISPs to advertise the speed actually achievable by 50% of customers during peak hours, not the theoretical max. In the US, ISPs are mostly free to use the higher number. Hence the gap.

The one number that actually matters

For most users, the number that actually matters isn't the headline Mbps. It's whether the connection is fast enough for what you do:

4K Netflix: 25 Mbps sustained per stream
Zoom HD: 3 Mbps down + 3 Mbps up per participant
Gaming: Bandwidth doesn't matter (most games use <1 Mbps); latency does
Cloud backup / upload: Upload bandwidth is the bottleneck, not download
WFH video calls: Upload bandwidth + jitter + packet loss matter more than download

If your connection delivers all of that comfortably even during peak hours, you're getting what you need. The fact that the speed test shows 187 instead of 300 is annoying but not actually a problem.

If your connection doesn't deliver the above — if your Zoom drops, your uploads stall, your gaming lags — then the speed test number is the diagnostic tool, not the goal. Run our speed test at different times of day, compare to peers on the same ISP, and use the gap to argue your case if you have to.