Storage & data rates

File transfer time: turn a size and a speed into an honest lower-bound estimate

Transfer time is simple arithmetic once the units match: divide the file size by the data rate. The mistakes usually come from mixing bits with bytes, decimal units with binary units, or an interface's headline rate with real payload throughput.

Quick answerFor decimal units, a 10 GB file contains 10,000 MB. At a sustained 500 MB/s, the ideal transfer time is 20 seconds. If the speed is written as 1,000 Mb/s instead, divide by eight first: 1,000 Mb/s is 125 MB/s, so the same 10 GB would need at least 80 seconds at that raw rate.

Use the calculator, then read the caveat

Ideal file transfer time calculator

This is a unit-and-time calculator, not a benchmark. It assumes the selected rate stays constant and that every unit of the rate is useful file payload.

The core formula is size divided by rate

Time is the amount of data divided by the amount of data moved per second. If the file size and transfer rate are both expressed in compatible byte units, the result falls out directly.

time in seconds = file size in MB ÷ transfer rate in MB/s

For a decimal 10 GB file, 10 GB equals 10,000 MB because the SI prefix giga represents 109 and mega represents 106. At a sustained 500 MB/s:

10,000 MB ÷ 500 MB/s = 20 seconds

The arithmetic is exact for the stated units. The real-world assumption — that the transfer actually sustains 500 MB/s from start to finish — usually is not.

If the speed is in Mb/s, convert bits to bytes first

A lowercase b means bit. An uppercase B means byte. One byte contains eight bits, so a rate expressed in megabits per second must be divided by eight before it can be compared directly with a file size expressed in megabytes.

For example:

1,000 Mb/s ÷ 8 = 125 MB/s

Using the same decimal 10 GB file:

10,000 MB ÷ 125 MB/s = 80 seconds

This is why a 1 Gb/s network connection and a 125 MB/s storage rate can represent the same raw data rate even though the printed numbers look very different. For the full unit explanation, see MB/s versus Mb/s.

Decimal GB and binary GiB are not the same quantity

NIST defines SI prefixes such as kilo, mega, giga, and tera as powers of ten. NIST also documents separate binary prefixes such as kibi, mebi, gibi, and tebi for powers of two. That means:

The calculator on this page deliberately uses decimal GB and decimal MB/s so the conversion is visible and predictable. If an operating system reports a file size in GiB or a utility reports MiB/s, convert both quantities to bytes or to matching binary units before dividing. The related storage-capacity guide explains the decimal/binary distinction in more detail.

Why the real transfer is usually slower

A theoretical transfer-time calculation assumes one stable payload rate. Real systems contain several stages that can reduce or vary that rate.

StageWhy the headline number can overstate file-copy speed
Network or bus protocolHeaders, framing, encoding, acknowledgements, and error handling consume part of the raw signaling capacity.
Source storageThe sender may not be able to read the file as quickly as the interface can theoretically carry it.
Destination storageWrite speed, cache exhaustion, garbage collection, or thermal behavior can reduce sustained throughput.
Many small filesMetadata operations and per-file overhead can make a folder copy much slower than one large sequential file with the same total size.
Wireless linksSignal quality, contention, retransmissions, and airtime sharing make sustained payload rate vary over time.
Remote downloadsThe server, route, congestion, and application can all become bottlenecks before the local link reaches its headline speed.

The slowest useful stage sets the practical ceiling

If a laptop has a 10 Gb/s interface but the source drive only reads at 350 MB/s, the interface does not make the source produce data faster. The same principle applies in the opposite direction: a very fast SSD cannot make a 1 Gb/s network deliver a file faster than the network path allows.

A useful estimate therefore starts with the sustained rate you expect the whole path to deliver, not automatically with the largest number printed on any one component. When that sustained rate is unknown, calculate several scenarios instead of pretending one number is guaranteed.

Scenario table: the same 100 GB at different sustained rates

Sustained payload rateIdeal time for decimal 100 GBInterpretation
125 MB/s800 s ≈ 13 min 20 sEquivalent to 1,000 Mb/s before real protocol overhead
500 MB/s200 s ≈ 3 min 20 sRepresentative arithmetic for a moderate sustained local copy
1,000 MB/s100 s ≈ 1 min 40 sRequires the entire path to sustain about 1 GB/s of payload
2,000 MB/s50 sFast interfaces alone do not guarantee this sustained file rate

Do not confuse link rate with payload rate

USB-IF's consumer-facing data-performance guidance uses signaling-rate labels such as USB 5Gbps, USB 10Gbps, USB 20Gbps, USB 40Gbps, and USB 80Gbps. Those labels describe product signaling capability. They are not a promise that a file-transfer application will deliver the same numeric rate as useful payload.

The same caution applies to Ethernet, Wi-Fi, storage buses, and external-drive interfaces. A specification can establish the transport ceiling while the actual transfer is constrained elsewhere. The calculator is most useful when the input rate is a measured or realistically sustained rate from the path you care about.

A reliable estimation workflow

  1. Write down the file size with its exact unit: GB, GiB, MB, or MiB.
  2. Write down the transfer rate with capitalization intact: MB/s is not Mb/s.
  3. Convert both quantities into compatible units before dividing.
  4. If the rate is a link/interface maximum, label the result as a theoretical lower bound.
  5. For planning, also calculate a slower sustained-rate scenario to account for the likely bottleneck.

Primary sources

Bottom line

Match the units, divide size by rate, and treat the result as a lower bound unless the rate is a sustained payload measurement. The math is easy; the useful part is refusing to confuse a transport ceiling with the speed of the complete transfer path.