Bandwidth is the maximum amount of data a connection can carry per second. Throughput is the amount that actually gets through. Bandwidth is the number on your internet bill, and throughput is what you measure on a given device, at a given moment, to a given destination. Throughput is almost always lower, and the gap between the two is where most "I pay for fast internet but everything lags" problems live.
This guide explains the difference in plain terms, shows why the numbers drift apart, and gives you a way to measure both, whether you stream, game, work remotely or just want to know what you are paying for.
TL;DR
- Bandwidth is capacity: the most your link or plan can carry, usually quoted in Mbps or Gbps.
- Throughput is delivery: the rate of data that actually arrives, measured over real traffic. It is always at or below bandwidth.
- Latency, packet loss, Wi-Fi quality, protocol overhead, congestion and the server on the other end all pull throughput below bandwidth.
- "Speed" in advertising usually means bandwidth. A speed test result is closer to throughput.
- For streaming and calls, check upload throughput, latency and jitter, not just the headline download number.
Table of Contents
- The short version: capacity versus delivery
- What bandwidth really means
- What throughput really means
- Why throughput falls below bandwidth
- Bandwidth vs speed: why the words blur
- Worked example: a 300 Mbps plan
- How to measure both
- Why this matters for livestreamers
- Perspective: why we look past the headline number
- Choosing the right plan from what you measured
- Quick reference: terms people confuse
- FAQ
- Sources
The short version: capacity versus delivery
The classic picture is a pipe. Bandwidth is the width of the pipe, and throughput is how much water actually comes out the other end per second. A wide pipe with a kink in it, a leak, or a clogged filter at the far end still delivers less than its width allows.
TechTarget's explainer draws the same line: bandwidth refers to capacity, while throughput describes how much data actually transmits. Both are expressed in bits per second, which is why people mix them up. They answer different questions, though.
| Bandwidth | Throughput | |
|---|---|---|
| What it describes | Maximum capacity of a link or plan | Actual data delivered |
| Typical unit | Mbps, Gbps | Mbps, Gbps (sometimes packets per second) |
| Where you see it | Your ISP plan, your Ethernet or Wi-Fi link rate | A speed test, a file transfer, a monitoring tool |
| Changes over time | Rarely (when you change plans or hardware) | Constantly |
| Can exceed the other? | Never lower than throughput on the same path | Never higher than the bottleneck's bandwidth |
| Question it answers | "How much could I move?" | "How much am I moving?" |
What bandwidth really means
Bandwidth has a few meanings, and the context decides which one applies.
Your plan. A 500 Mbps plan is a promise about the capacity your provider provisions for your line. It is a ceiling, not a guarantee about what any one website or app will receive.
Your link rate. Your Wi-Fi adapter may report a link speed of 866 Mbps or 1,200 Mbps. That is the negotiated physical rate between your device and the router. It is the radio's capacity under good conditions, and it is not the rate you can move files at, because Wi-Fi shares airtime and spends part of it on its own overhead.
Your bottleneck. Every path has many links: your device, your router, your ISP's access network, the internet backbone, the destination's servers. The bandwidth that matters for any transfer is that of the narrowest, busiest link on the path.
The IETF describes this idea formally in RFC 9097, which defines metrics and methods for measuring one-way IP capacity, meaning the maximum rate a network path can carry. Capacity is a property of the path, not of the plan on your invoice.
What throughput really means
Throughput is the rate at which data is successfully delivered over a path during a measured interval. Three details matter:
- It is measured, not specified. You cannot read throughput off a box. You observe it.
- It depends on what you measure. Throughput of a single TCP download from one server is different from the total throughput of every device in your house.
- It may count different things. Raw throughput counts every bit on the wire, including headers and retransmissions. Goodput counts only the useful payload, such as the actual bytes of your file. Application-level numbers (what a file transfer or video player reports) are closer to goodput.
A field example shows how much this can vary even between networks that look similar on paper. In a 2024 ITU workshop presentation, a comparison of two mobile operators showed average downlink application throughput of 68.9 Mbps on one and 109.4 Mbps on the other, a 59% difference, measured under the same test approach. Same technology generation, same country, very different delivered throughput.
Why throughput falls below bandwidth
This is the part most explainers skip, and it is the most useful. Here are the usual culprits, roughly from most to least common in homes.
Wi-Fi conditions
Distance, walls, interference from neighbors and the number of devices competing for airtime all cut throughput. The link rate on your laptop can stay high while the real transfer rate halves because the channel is busy. Moving a stream or game console to Ethernet often delivers the biggest single improvement. We cover when that is worth it in our Ethernet vs Wi-Fi guide for streamers.
Latency and the TCP window
Most web traffic runs over TCP, which only lets a limited amount of unacknowledged data be in flight at once. If the sender can have 64 KB outstanding and the round trip takes 50 ms, the ceiling is about 10.5 Mbps for that single connection (65,536 bytes × 8 bits ÷ 0.05 s), no matter how fat your plan is. Modern systems scale the window up automatically, but high latency to a distant server still limits what one connection achieves. This is why a download from a server across an ocean can feel slower than one from a nearby server on the same line.
Packet loss and retransmission
When packets are lost, TCP slows down to avoid making congestion worse and resends what went missing. Even a small loss rate can cut throughput sharply on long paths. Loss on a weak Wi-Fi link or a flaky cable connection is a classic cause of a connection that tests well in short bursts but stutters in practice.
Congestion and bufferbloat
When your link is full, packets queue up in buffers. Oversized buffers keep throughput looking healthy while latency explodes, so calls freeze and games rubber-band whenever someone uploads a large file. The IETF's responsiveness test draft exists because of this: it aims to measure user experience under working conditions, when the network is loaded, rather than on an idle line.
Protocol overhead
Ethernet, IP, TCP, TLS and VPN encapsulation each add headers. On a typical connection that is a few percent. A VPN can cost more, both in overhead and in the extra distance to the VPN server. If you are testing through one, read how to run a VPN bandwidth test the right way.
The other end
A busy server, a throttled CDN node or a congested peering point between networks will cap your throughput regardless of your plan. A single slow website does not mean your line is slow.
Hardware limits
An old router, a 100 Mbps Ethernet port or a USB adapter can silently cap a gigabit plan. Check each device in the chain before blaming the provider.
Bandwidth vs speed: why the words blur
People search for "bandwidth vs speed" because ISPs sell "speed" and engineers say "bandwidth." In marketing, speed nearly always means the plan's bandwidth, quoted as "up to" a number. In everyday use, "my speed is slow" means low throughput.
True speed in the sense of how fast a single bit travels is closer to latency: the time it takes for data to get to the destination and back. A 1 Gbps link and a 100 Mbps link can both have a 20 ms round trip. Bandwidth decides how much arrives per second. Latency decides how soon the first piece arrives.
So when someone asks whether they need "more bandwidth or more speed," the useful answer is to find out which constraint hurts:
- Large downloads and 4K streams are slow: you likely need more throughput, which can mean more bandwidth, a better Wi-Fi path or fewer competing devices.
- Calls freeze, games lag, pages feel sluggish even though downloads are fast: the problem is probably latency, jitter, loss or bufferbloat. More bandwidth rarely fixes it.
- Your stream drops frames: upload throughput and stability are the problem. See the livestream section below.
Worked example: a 300 Mbps plan
Say you pay for 300 Mbps download and 20 Mbps upload. You run a test on your laptop in a back bedroom and see 140 Mbps down and 12 Mbps up. Is the ISP cheating you?
Walk down the chain:
- Test next to the router, or over Ethernet. If the number jumps to 280 Mbps, your line is fine and Wi-Fi was the bottleneck.
- Test with other devices idle. A cloud backup or a 4K stream elsewhere in the house shares the same capacity.
- Test at different times. If evening results drop sharply while mornings are fine, you may be seeing congestion on the shared access network.
- Look beyond download. If download looks fine but video calls glitch, check latency, jitter and loss.
- Keep a record. Results from several times of day tell a story that one test cannot. This is also the evidence to hand your ISP if the line itself underperforms.
Our speed guide on why you may not be getting the speed you paid for goes through this process in more detail.
How to measure both
Bandwidth is usually something you read: your plan details, your router's WAN port speed, your Wi-Fi link rate. The best proxy for line capacity is a speed test run over Ethernet, to a nearby server, with nothing else on the network.
Throughput is something you test under the conditions you care about:
- Run the test on the device and connection you actually use (Wi-Fi in the room where you work, not just next to the router).
- Test several times and at different hours.
- Record download, upload, latency, jitter and packet loss together. A throughput number without latency and loss hides half the story.
- For a specific application, test throughput to that application's servers, or use a test built for that use.
The Speed Test on GrandSpeed reports download and upload speeds along with latency, jitter, packet loss, bufferbloat and DNS resolution time, and keeps a history so you can compare results over days. If you are testing upload specifically, this walkthrough on running a free bandwidth test for upload speed covers the setup, and why your upload speed may be so slow covers the fixes.
Why this matters for livestreamers
For streaming, the difference between bandwidth and throughput decides whether your broadcast holds up. YouTube's guidance is explicit: the total bitrate you stream cannot exceed your available upload bandwidth, and it recommends leaving about 20% of headroom. It also notes that inbound bandwidth (download) is often greater than outbound, so a speed test should confirm your outbound connection is sufficient.
Here is the trap: your plan may list 20 Mbps upload (bandwidth), but your sustained upload throughput to the ingest server might be 14 Mbps because of Wi-Fi, loss or an evening-congested route. If your encoder sends 10 Mbps video plus audio, you have thin margins, and a dip will trigger buffering or dropped frames. Plan on throughput, not on the plan.
A practical sequence:
- Test upload several times over Ethernet at the hours you plan to stream.
- Take the lower, consistent number, not the best run.
- Set your total stream bitrate (all video, audio and any multistream outputs) at roughly 80% of that figure or below.
- Watch the connection during the stream rather than trusting a test from last week.
The GrandSpeed Livestream Upload Speed Monitor is built for the last step, and our video bitrate planner helps you turn a measured upload number into a bitrate that fits. If you stream to several platforms at once, remember that each output adds to the load. Our multi-streaming guide covers that math.
Perspective: why we look past the headline number
We built GrandSpeed because a single download figure answers one narrow question, and most of the complaints we hear are about something else: a call that freezes, a stream that buffers, a game that spikes, on a plan that tests "fast." In our experience, the useful move is to stop asking "how much bandwidth do I have?" and ask "what throughput and stability do I get for the thing I am doing?"
That is why our tests report jitter, packet loss, bufferbloat and DNS timing alongside download and upload, and why we translate results into what they allow, such as the maximum stream resolution your measured speeds support. A number only helps when it is tied to a task. We also encourage keeping history. One result is an anecdote, but a week of results at different hours is a diagnosis, and it is far more persuasive when you call your provider.
The pattern we see most is that people upgrade their plan to fix a problem that lives in their Wi-Fi or in an unmanaged queue on their router. Measure first, then spend.
— Peter D
Choosing the right plan from what you measured
Once you know your real throughput, you can size a plan with less guesswork. Count the simultaneous demands in your home at peak time: video calls, streams, game downloads, cloud backups, and uploads if you create content. Add headroom, because throughput never reaches the plan's ceiling in practice.
If you want a shortcut, the Internet/ISP Speed Recommender suggests the speed tier that fits your use. For video work, our guide to streaming data usage and bitrate shows how to size from 2 to 3 minute tests.
And if your measured throughput is much lower than your plan, skip the upgrade and fix the cause first: move to Ethernet, reposition or replace the router, reduce competing traffic, then contact your provider with your test history.
Quick reference: terms people confuse
- Bandwidth: the capacity of a link or plan.
- Throughput: the measured rate of data actually delivered.
- Goodput: throughput of useful payload only, excluding headers and retransmissions.
- Latency: the delay for data to travel to a destination and back.
- Jitter: variation in that delay from packet to packet.
- Packet loss: the share of packets that never arrive and must be resent or skipped.
- Bitrate: the data rate of a media stream, such as a 6 Mbps video. It must fit inside your throughput, not just your bandwidth.
FAQ
Are throughput and bandwidth the same?
No. Bandwidth is the maximum a connection can carry, while throughput is what actually gets delivered at a given time. Throughput can approach bandwidth on a clean, idle wired link, but it is never above the bottleneck's capacity. In everyday use the two get mixed up because both are quoted in Mbps.
Is higher or lower throughput better?
Higher is better, as long as it is stable. A connection with high throughput that swings widely, or that comes with high latency and packet loss, can feel worse than a slower but steady one. For streaming and calls, consistency matters as much as the peak.
What does throughput mean in Wi-Fi?
Wi-Fi throughput is the real data rate your device gets over the wireless link, after interference, shared airtime and protocol overhead. It is lower than the link rate your device reports, often substantially. Test in the room where you use the device, and compare against a wired test to see how much Wi-Fi costs you.
Do I need more bandwidth or more speed?
It depends on the symptom. Slow big downloads and crowded households point to needing more throughput, which may mean more bandwidth. Laggy calls, game spikes and sluggish browsing on a fast plan point to latency, jitter, loss or bufferbloat, which more bandwidth often does not fix. Run a test that reports all of them before buying anything.
Why is my speed test lower than my plan?
The plan is a ceiling, and the test measures throughput along a real path. Wi-Fi, other devices, an older router, a distant test server or congestion can each reduce the result. Test over Ethernet with other devices idle to see what the line itself delivers.
Sources
- Network bandwidth vs. throughput: What's the difference? (TechTarget)
- RFC 9097: Metrics and Methods for One-Way IP Capacity (IETF)
- IETF draft: Responsiveness Test (draft-ietf-ippm-responsiveness-09)
- ITU workshop presentation on mobile QoS benchmarking, 2024 (Graham Kemp)
- Streaming tips (YouTube Help)
- Streaming tips, outbound speed note (YouTube Help)