Download Time Calculator

Introduction to estimating download time

Waiting on a download is a small planning problem with a useful answer: is this a grab-a-coffee download, a go-for-a-walk download, or a leave-it-overnight download? This tool turns a file size and a connection speed into an estimated transfer duration, and it does the unit juggling that trips up most back-of-the-envelope guesses — bytes versus bits, decimal megabytes versus binary mebibytes, and the protocol overhead that separates your line rate from the rate the file actually arrives at.

Two numbers drive the whole calculation. The first is the file size, which you can enter in MB, GB or TB (decimal, powers of ten) or in MiB, GiB or TiB (binary, powers of two). The second is the connection speed, which you can enter in Kbps, Mbps or Gbps if you are quoting a plan speed, or in KB/s or MB/s if you are copying the figure straight out of a download manager. A third optional field, protocol overhead, converts the raw line rate into usable goodput so the estimate lands closer to reality.

How to use the download time estimator

1. Type the file size and pick the matching unit. If the number came from Windows Explorer, choose the binary unit (GiB) — Windows prints binary sizes with decimal labels.
2. Type your connection speed and pick its unit. Use a measured speed if you have one; an advertised plan speed is an upper bound, not a promise.
3. Optionally adjust protocol overhead. The default of 10 percent is a reasonable wired-connection starting point.
4. Activate Estimate Time. You get the ideal duration, the realistic duration after overhead, the effective byte rate, and the payload expressed in both megabytes and megabits.
5. Read the bar chart underneath: it replots your file across seven common speed tiers so you can see how much a faster plan would actually buy you.
6. Then try the Bandwidth Pipeline game further down the page. It hands you a small network of links quoted in mixed units and asks you to route the file to the client before a deadline, which is the same size-divided-by-rate arithmetic under time pressure.

Bits versus bytes: the factor of eight

File sizes and network speeds look similar but count different things:

• File size is measured in bytes: kB, MB, GB, TB.
• Network speed is measured in bits per second: Kbps, Mbps, Gbps.
• The bridge between them is 1 byte = 8 bits.

That means a 100 Mbps connection does not move 100 MB every second. Under ideal conditions it moves about 12.5 MB every second, because MB/s = Mbps ÷ 8:

This factor of eight is the whole reason a download can feel disappointing on paper. Marketing quotes the bigger-sounding bits-per-second number, while your file manager and your storage device talk in bytes. A gigabit fibre plan advertised as 1000 Mbps delivers at most about 125 MB/s, and a 12 Mbps mobile hotspot is really about 1.5 MB/s. Whenever an estimate looks eight times too slow or too fast, a bit-versus-byte mix-up is almost always the cause, so it is worth checking which unit each number is in before trusting the answer.

The download time formula

The calculation is a single division once both quantities are in the same base unit. Convert the file size to bits by multiplying bytes by eight, then divide by the connection speed in bits per second:

Where:

• t = transfer time in seconds
• S = file size in bytes
• R = connection speed in bits per second

Plain-text formula: time_seconds = fileSizeBytes * 8 / speedBitsPerSecond, and realistic_seconds = time_seconds / (1 - overheadFraction). To convert, multiply MB by 1e6, GB by 1e9, MiB by 1048576, GiB by 1073741824, Mbps by 1e6, Gbps by 1e9 and MB/s by 8e6.

Real links never deliver the full line rate to your file, because every packet carries headers. Model that with an overhead fraction o — the share of the line rate consumed by framing rather than payload — and divide by the remainder:

Dividing by 1 − o rather than multiplying by 1 + o matters once the overhead is large: at 10 percent the two agree within one percent, but at 40 percent overhead the correct factor is 1.67, not 1.4. Overhead reduces the rate, and time is inversely proportional to rate.

Decimal GB versus binary GiB

Storage and networking disagree about what a prefix means, and the disagreement is worth real minutes on a large download. The SI prefixes used by drive manufacturers, macOS and most Linux tools are powers of ten. The binary prefixes standardised by IEC 80000-13 are powers of two. Windows uses binary sizes but prints the decimal symbols, which is where most of the confusion starts.

The binary unit is 4.9 percent larger at the megabyte scale, 7.4 percent larger at the gigabyte scale and 10.0 percent larger at the terabyte scale. For a 40 GiB game that is nearly three gigabytes of extra data, which on a 100 Mbps line is about four extra minutes.

Worked example: a 5 GB game update on a 50 Mbps line

Scenario: a store lists a game update as 5 GB and your plan is 50 Mbps.

1. Convert the size to bytes: 5 GB × 1,000,000,000 = 5,000,000,000 bytes
2. Convert bytes to bits: 5,000,000,000 × 8 = 40,000,000,000 bits
3. Convert the speed to bits per second: 50 Mbps × 1,000,000 = 50,000,000 bit/s
4. Divide: 40,000,000,000 ÷ 50,000,000 = 800 seconds
5. Express it in minutes: 800 ÷ 60 ≈ 13.33 minutes → 13 minutes 20 seconds
6. Apply 10 percent overhead: 800 ÷ 0.90 ≈ 889 seconds → 14 minutes 49 seconds

Reality check: if that store actually meant 5 GiB, the file is 5,368,709,120 bytes and the ideal time rises to 859 seconds — 14 minutes 19 seconds — before overhead. So the honest planning answer for this download is "about a quarter of an hour", and the difference between the two unit conventions is smaller than the difference a busy evening makes.

Reading the result and the speed-tier chart

The calculator returns a best-effort estimate from the numbers you supply, so it helps to think in ranges rather than exact clock times:

• On a stable wired connection, real results usually land within a few percent of the overhead-adjusted figure.
• On Wi-Fi or a shared household connection, real times vary widely through the day.
• Downloading from a busy server, a game launcher or a throttled mirror caps you well below your line rate, and no amount of extra bandwidth helps.

The bar chart under the form plots your file against seven common speed tiers. Because time is inversely proportional to rate, the bars fall away steeply at the low end and flatten at the high end — going from 10 to 50 Mbps saves far more wall-clock time than going from 500 to 1000 Mbps. That curve is the single most useful thing to know before paying for a faster plan.

Quick comparison table: common download scenarios

These examples assume ideal conditions, decimal file-size units and no overhead, using exactly the same arithmetic as the tool.

How connection speed changes the picture

The same file feels very different depending on the connection behind it. Doubling your megabits per second halves the wait, so the gap between plans grows with file size and shrinks with speed. The table below shows the ideal-condition time for a 10 GB download across common tiers, so you can see where your own plan lands.

Limitations and assumptions behind the estimate

This calculator produces an estimate, not a guarantee. Real download times differ because of:

• Protocol overhead. On a 1500-byte Ethernet MTU, an IPv4 header (20 bytes) plus a TCP header (20 bytes, or 32 with timestamps) plus Ethernet framing and the interframe gap consume roughly 6 percent of the raw line rate before TLS is even considered.
• Congestion and shaping. Speeds fluctuate at peak hours, on shared coaxial segments and on mobile networks, and some plans shape sustained transfers after a data threshold.
• Server and CDN limits. The host may cap each connection far below your capacity; multi-connection download managers exist precisely because of this.
• Wi-Fi behaviour. The nominal radio rate is a shared, half-duplex, best-case figure that falls with distance, interference and the number of active clients.
• Speed tests versus real throughput. A speed test measures a short burst to a nearby, well-provisioned server, which is rarely the route your actual download takes.
• Slow start and short files. TCP ramps its congestion window up over the first few round trips, so files under a few megabytes finish before the connection ever reaches full speed. The estimate assumes a steady-state rate.
• Unit conventions. The tool assumes decimal prefixes for the units labelled MB, GB and TB and binary prefixes for MiB, GiB and TiB. Speeds in Kbps, Mbps and Gbps are always decimal, which is the universal networking convention.

Tips for more accurate download planning

• If you know your typical measured throughput, use that instead of the advertised plan speed.
• If your download manager reports MB/s, select the MB/s speed unit rather than converting by hand.
• For very large transfers, budget an extra 10 to 25 percent on top of the overhead-adjusted figure to absorb congestion.
• Prefer a wired connection for multi-gigabyte downloads; it removes the largest and least predictable source of loss.
• On a shared connection, start the download when the network is quiet — peak-hour congestion is usually the single biggest gap between the estimate and reality.

Sources: unit definitions follow the NIST reference on prefixes for binary multiples and the SI decimal prefixes in the BIPM SI Brochure. Header sizes used for the overhead figures come from RFC 791 (Internet Protocol) and RFC 9293 (Transmission Control Protocol), and the gap between advertised and delivered speeds is documented in the FCC's Measuring Broadband America reports. Last reviewed August 2026.

Download time: frequently asked questions