Bandwidth Calculator

The formula

time (s) = (size_GB × 8 × 10⁹) ÷ (speed_Mbps × 10⁶ × efficiency ÷ streams)

Megabits are not megabytes

ISPs advertise in megabits per second while operating systems report file sizes in megabytes. One byte is eight bits, so a "1 Gbps" connection moves at most 125 MB/s in theory and about 112 MB/s in practice once overhead is removed. This single unit confusion accounts for most "my internet is slower than advertised" complaints. The overhead is real and unavoidable: Ethernet framing, IP and TCP headers, TLS records and acknowledgements consume roughly 8–15% of the raw link rate, which is why the efficiency field defaults to 90%.

Bandwidth vs. latency: which one is actually slow

Bandwidth is how much you can move per second; latency is how long a single packet takes to arrive. A video call stutters because of latency and jitter, not because the link is too small — 5 Mbps is plenty for 1080p. A large file transfer crawls because of bandwidth. Diagnosing the wrong one wastes money: upgrading from 100 Mbps to 1 Gbps does nothing for a Zoom call that keeps breaking up, while removing hops or moving the workload to a nearer region does. As a rule, if small interactive tasks feel slow, fix latency; if bulk copies feel slow, fix bandwidth.

Why adding a second download halves both

TCP congestion control is designed to share a bottleneck fairly, so two flows on one link each settle at roughly half the capacity rather than one finishing at full speed. This is useful when you want fairness and annoying when you want the backup to finish. Priority queuing and traffic shaping exist precisely to break that symmetry — they let you cap bulk transfers so interactive traffic keeps its latency.

Frequently asked questions

Why is my download slower than the speed test?
Speed tests measure a short burst to a nearby server with empty buffers. Sustained transfers are limited by the remote server's capacity, TCP congestion windows over long distances, Wi-Fi interference and competing traffic on your own network.
How much bandwidth does 4K streaming need?
About 15–25 Mbps per stream for compressed services (Netflix recommends 15 Mbps), 50–100 Mbps for high-bitrate sources, and 400 Mbps or more for uncompressed professional video.
What efficiency should I assume?
Around 90–94% for a clean wired LAN, 85–90% for typical internet transfers with TLS, and 60–75% for congested or long-fat networks where packet loss forces retransmission.
Does fibre remove protocol overhead?
No. Overhead comes from the protocols, not the medium. Fibre improves latency and achievable throughput but the same framing and header costs apply.

Source & methodology

Standard throughput model (bits ÷ usable rate); overhead figures from IEEE 802.3 Ethernet framing and TCP/IP header analysis per RFC 1122.

How Bandwidth works — and what your result really means

You are here because you need a specific number, and you want to see how it was produced before you rely on it. Searchers land on a Bandwidth page for three reasons — to plan, to compare options, and to check that somebody else’s arithmetic is honest. This tool serves all three, and everything after the calculator explains the model instead of hiding it.

The useful way to hold Bandwidth is as a ratio with a story attached: time (s) = (size_GB × 8 × 10⁹) ÷ (speed_Mbps × 10⁶ × efficiency ÷ streams) says how the parts combine, and the 4h 56m 18s figure above is simply that sentence written in numbers. Everything that follows unpacks one clause of the sentence at a time.

The number itself is the easy part. What takes judgement is knowing which inputs are facts in your situation and which are guesses wearing a decimal point — a distinction this page makes explicit for every field above.

Nothing below is stock text pasted around a number: the worked example computes transfer time = 4h 56m 18s from this tool’s own defaults. Work down the page and by the end you could re-derive the result in a spreadsheet from memory.

Every input in Bandwidth, and what it does to the answer

One formula, published in full: time (s) = (size_GB × 8 × 10⁹) ÷ (speed_Mbps × 10⁶ × efficiency ÷ streams). Anything you can read, you can reproduce in a spreadsheet, and that reproducibility is the whole point of printing it rather than hiding it behind a button.

Data to transfer (GB) (example value 500) is a plain measured quantity — the unit shown in the label is the unit the formula expects. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.

Link speed (Mbps) (example value 1,000) is a measured number in the unit named by the label; the formula does not convert for you. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.

Protocol efficiency (%) (example value 90) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. Check the convention first: if the source says “6.5 % per year”, type 6.5 and let the formula do the rest.

Concurrent transfers / streams (example value 4) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. Replace the example with the figure from your own records — the tool recomputes instantly and the printed steps follow your numbers.

Video bitrate per stream (kbps) (example value 8,000) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. The example value is there to demonstrate the mechanics, not to describe your situation — overwrite it.

The default Bandwidth calculation, written out in full

The tool prints its own working; this is the same arithmetic on the example values, reproduced so you can follow it by hand. Starting figures: Data to transfer (GB), Link speed (Mbps), Protocol efficiency (%), Concurrent transfers / streams. The endpoint of that chain is 4h 56m 18s of transfer time, sitting in the “500.0 GB over 1,000 Mbps at 90% efficiency” band.

  1. Convert size to bits: 500.00 GB × 8 bits/byte × 10⁹ = 4,000,000,000,000 bits.
  2. Usable rate per stream = link speed × efficiency ÷ concurrent streams = 1,000 × 90% ÷ 4 = 225.0 Mbps = 28.13 MB/s.
  3. Time = bits ÷ (Mbps × 10⁶) = 4,000,000,000,000 ÷ 225,000,000 = 17,777.8 s (4h 56m 18s).
  4. Video demand = 4 × 8,000 kbps = 32.0 Mbps against 900 Mbps usable → headroom 868.0 Mbps.

Effective throughput (total) — 112.50 MB/s. Compare it against the main result of 4h 56m 18s before drawing conclusions.

Per-stream throughput — 28.13 MB/s. This is the number experienced users quote when the headline alone would mislead.

Transfer time (seconds) — 17,777.8 s. If your inputs change, this is usually the first companion figure to move.

Bandwidth consumed by video — 32.0 Mbps. Compare it against the main result of 4h 56m 18s before drawing conclusions.

Remaining headroom — 868.0 Mbps. If your inputs change, this is usually the first companion figure to move.

Re-running with your own figures is instant; re-running by hand once is the best way to know the tool is telling you the truth.

Is your Bandwidth good — reading the result bands

A number on its own is trivia; a number against a range is intelligence. The default case lands in the “500.0 GB over 1,000 Mbps at 90% efficiency” band, and bands are deliberately wide because real situations overlap. The practical reading rules: compare against your own history before comparing against other people; treat band boundaries as zones, not walls — one point on the wrong side of a threshold rarely changes a real outcome; and when a companion output contradicts the headline, believe the pair.

Set Bandwidth beside its neighbours and it usually plays a specific role: this figure establishes the size of something, and the neighbouring tools establish whether that size is acceptable. Skipping the first step makes the second one arbitrary.

Common mistakes with Bandwidth (and the fix)

TCP congestion control is designed to share a bottleneck fairly, so two flows on one link each settle at roughly half the capacity rather than one finishing at full speed. This is useful when you want fairness and annoying when you want the backup to finish. Priority queuing and traffic shaping exist precisely to break that symmetry — they let you cap bulk transfers so interactive traffic keeps its latency.

Reusing a Bandwidth from last season. In Technology & Computing the inputs are the thing that drifts; the formula does not.

A final trap is presentation: reporting Bandwidth to more decimal places than the inputs support. The tool prints what the arithmetic gives; you should quote only what your least precise field justifies.

Bandwidth verification checklist

  • Recompute once with the dominant input deliberately set low, and see whether the decision changes.
  • Compare the result with one independent method or published benchmark.
  • Confirm the inputs are dated — a Bandwidth figure should carry the date it was computed.
  • Check that every field the formula needs actually arrived from a document, not from recollection.
  • Record the date and the inputs alongside the number so future-you knows what was assumed.
  • Confirm the answer against one independent method or published benchmark for Bandwidth.

Five steps from raw inputs to a figure you can defend

The tool does the arithmetic; the routine below is what makes the arithmetic trustworthy. Five steps, a minute total — and afterwards you will know not just what the number is, but which assumption produced it.

Step 1 — collect, then type. Everything this tool asks for is listed above (data to transfer (gb), link speed (mbps), protocol efficiency (%), concurrent transfers / streams, video bitrate per stream (kbps)). Pull each figure from something you can point at — paperwork, a dashboard, a label — before touching a field. Guesswork at the input stage cannot be repaired at the interpretation stage. Write the figure down before moving on; memory flatters whichever number you saw last.

Step 2 — start from the case you can defend. Enter pessimistic-but-honest figures first; the optimistic run is a ceiling, not a plan. A conclusion that holds on conservative inputs holds everywhere. The input you reach for first is usually the one you measured longest ago.

Step 3 — isolate your variables. Change one field, observe, revert. The live sensitivity list does the ranking for the default inputs; verify it against your own, because dominance shifts when the starting point shifts. A result worth acting on survives having its two shakiest inputs halved.

Step 4 — compute a corridor, not a point. Three runs — worst, likely, best — turn Bandwidth from a snapshot into a range. Plan against the pessimistic end and treat the optimistic end as the upside story. A figure with a date beside it becomes evidence; without one it stays an anecdote.

Step 5 — schedule the next run. In Technology & Computing the inputs drift quietly. Put a reminder a quarter out, re-enter the same fields, and read the change rather than the level. When in doubt, prefer the boring input: the interesting one is usually the one you misread.

From calculation to decision: where Bandwidth earns its keep

Technology & Computing arguments end at arithmetic or they do not end. Bandwidth is the arithmetic: 4h 56m 18s on the example inputs, reproducible by anyone who types the same numbers. Note the assumption you are least sure about; that is where the real risk lives.

Professionals in Networks & Storage use this style of calculation as a screening filter before spending real money or effort: a quick Bandwidth check eliminates weak options in minutes, and the survivors earn the deeper, slower analysis. Compare the calculation to the rough guess you arrived with, and ask why they differ.

There is a personal-administration use people overlook: periodic self-checking. Bandwidth quietly drifts as life changes — rates move, bodies change, costs compound — and re-running it a few times a year catches drift while correction is still cheap. Estimates improve most when the worst case is written down in ink.

People also ask about Bandwidth

What is a typical Bandwidth?

There is no honest universal average for Bandwidth, but there is a reference point: the defaults on this page produce 4h 56m 18s (500.0 GB over 1,000 Mbps at 90% efficiency). Replace the inputs with your own and compare — that comparison is the useful meaning of “typical”.

How do I calculate Bandwidth by hand?

time (s) = (size_GB × 8 × 10⁹) ÷ (speed_Mbps × 10⁶ × efficiency ÷ streams) is the entire method. Work the inputs in that order — Convert size to bits: 500.00 GB × 8 bits/byte × 10⁹ = 4,000,000,000,000 bits. — and you will reach 4h 56m 18s on the default figures, the same number this tool prints.

Is the Bandwidth result of 4h 56m 18s good or bad?

Good and bad are comparisons, so the honest test is three questions: where does your own Bandwidth sit against the 4h 56m 18s reference above, how far would a plausible input error move it, and what does the alternative option compute to?

Is Bandwidth accurate?

The arithmetic is exact: time (s) = (size_GB × 8 × 10⁹) ÷ (speed_Mbps × 10⁶ × efficiency ÷ streams) is evaluated with full floating-point precision and every substitution is printed in the worked example. What limits accuracy is input quality and the model’s assumptions, so treat the 4h 56m 18s result as the correct answer to the question you typed — and check the assumptions section before acting on it.

Can Bandwidth be negative or empty?

Yes, and that is informative rather than broken: a negative Bandwidth usually means the inputs encode an outflow or a shortfall, and the verdict band above labels exactly that situation instead of hiding it.

Why is my download slower than the speed test?

Speed tests measure a short burst to a nearby server with empty buffers. Sustained transfers are limited by the remote server's capacity, TCP congestion windows over long distances, Wi-Fi interference and competing traffic on your own network.

How much bandwidth does 4K streaming need?

About 15–25 Mbps per stream for compressed services (Netflix recommends 15 Mbps), 50–100 Mbps for high-bitrate sources, and 400 Mbps or more for uncompressed professional video.

Is my data private on this page?

Yes — computation happens locally in your browser, with no account, no tracking of your inputs and nothing sent to a server. The printed formula is the whole story of what happens to your figures.

Key terms on this page

Effective throughput (total)
112.50 MB/s in the default Bandwidth calculation — one of the secondary figures an experienced reader checks before trusting the primary number.
Per-stream throughput
28.13 MB/s for the Bandwidth worked case; it sits next to the main result because it carries context the headline leaves out.
Transfer time (seconds)
17,777.8 s on the example inputs — a companion figure printed beside the headline of Bandwidth so that no result is read in isolation.
Transfer time
The primary output of this tool: 4h 56m 18s for the default inputs, computed exactly from time (s) = (size_GB × 8 × 10⁹) ÷ (speed_Mbps × 10⁶ × efficiency ÷ streams).
Worked example
The step-by-step substitution printed above, so the arithmetic can be re-derived by hand or in a spreadsheet.
Verdict band
The plain-language label — here “500.0 GB over 1,000 Mbps at 90% efficiency” — mapping the computed figure onto experience-based ranges for Technology & Computing.

Where the Bandwidth model comes from

There is no black box on this page — the engine evaluates time (s) = (size_GB × 8 × 10⁹) ÷ (speed_Mbps × 10⁶ × efficiency ÷ streams). Source of record: Standard throughput model (bits ÷ usable rate); overhead figures from IEEE 802.3 Ethernet framing and TCP/IP header analysis per RFC 1122. Specialist software layers extra coefficients on top of the same algebra; none are hidden here, and that transparency is what makes a disagreement traceable to a specific input instead of a black box.

Treat the output as a precise answer to the question you typed: exact arithmetic, transparent formula, published source, no hidden rounding. The promise to the reader is narrow and testable: same inputs, same output, no silent rounding, and no figure presented without the formula that produced it.

What to do with your Bandwidth next

Save the number together with its inputs and today’s date; a Bandwidth figure without context is unusable the moment an input changes.

Whoever you are (people who need one trustworthy number before their next decision), the next step is the same: replace the example inputs with your own, note the date, and re-run whenever a figure moves. In Technology & Computing, a dated figure is a trend, and an undated one is a rumour.