▸ Free tool
Data Transfer Time Calculator.
How long does it take to move X at Y bandwidth? Enter a size and a link rate, pick a base, and get a real answer — with the overhead that line-rate maths always forgets.
▸ Units matter
Link speed is bits. File size is bytes. The factor of 8 between them is where most transfer estimates go wrong — this tool keeps them apart.
▸ Cloud bills and drive labels are decimal. ls -lh and Windows are binary.
▸ Link rates are always decimal. MB/s here means 10⁶ bytes/s.
▸ Share of line rate you actually get. 85% is a sane wired default.
▸ Transfer time
—
—
- At full line rate
- —
- Effective throughput
- —
- Payload
- —
▸ Check the inputs
Runs in your browser · nothing uploaded
Common links.
| Scenario | Link rate | Efficiency | Apply |
|---|---|---|---|
| Home broadband Wired, single stream, ISP line rate | 100 Mbps | 85% | |
| Gigabit fibre Wired LAN or same-region cloud | 1 Gbps | 90% | |
| Datacenter east-west Jumbo frames, tuned windows, short RTT | 10 Gbps | 92% | |
| 5G mobile Wildly variable — assume the low end | 200 Mbps | 60% | |
| S3 multipart upload 8 parallel parts over a 1 Gbps uplink | 1 Gbps | 75% |
Bits, bytes, and the factor of 8
Link speeds are sold in bits per second. Files are measured in bytes. One byte is eight bits, so a 100 Mbps line moves at most 12.5 MB/s, and a 1 GB file needs at least 80 seconds on it — not 10. Nearly every "why is my transfer so slow" thread starts and ends right here.
The unit selector keeps the two apart on purpose. Pick Mbps or Gbps when
you are reading a spec sheet, an ISP plan, or a NIC. Pick MB/s when you
are reading a progress bar in Finder, rsync, or the AWS CLI. One thing this calculator deliberately does not do:
it treats MB/s as 10⁶ bytes per second, because network rates are
decimal by convention even when the file size sitting next to them is
binary. If your transfer tool reports MiB/s, multiply by 1.048576 before
typing it in.
1000 or 1024 — pick one and say which
A "1 TB" drive holds 1,000,000,000,000 bytes. The same drive shows up as 931 GB in Windows, because Windows divides by 1024 four times and still writes "GB". Those are two different numbers, 9.95% apart, and at terabyte scale that gap alone is an extra half hour of copying.
The base selector switches between them. Decimal (KB/MB/GB/TB, powers of
1000) is what drive vendors, cloud object stores, and storage invoices
mean. Binary (KiB/MiB/GiB/TiB, powers of 1024) is what ls -lh, du -h, and Windows Explorer mean, even
when the label quietly drops the "i". Match whichever source you read
the size from — not the one that gives you the answer you were hoping
for. The exact byte count is printed with every result so you can sanity
check it.
Why you never hit line rate
The headline number here is not size divided by link speed, because you will never get the link speed. The efficiency field defaults to 85% for four reasons:
- Framing overhead. A standard 1500-byte Ethernet frame carries 1460 bytes of TCP payload — 20 bytes of IP header, 20 of TCP header, plus 38 bytes of Ethernet framing and inter-frame gap on the wire. That is roughly 5-6% gone before anything goes wrong, and TLS record overhead takes a little more.
- The bandwidth-delay product. A single TCP connection can
only have one receive window in flight at a time, so window divided by round-trip
time is a hard ceiling. A 64 KB window over a 100 ms path tops out at 5.2
Mbps no matter how fat the link is. To fill 1 Gbps at 100 ms RTT you need
12.5 MB in flight, which means window scaling and buffers large enough to
hold it. This is why a cross-region
scpcrawls whileaws s3 cpwith multipart concurrency saturates the same link. - Congestion control. CUBIC and BBR both spend the first round trips ramping. Short transfers may never leave slow start; long ones lose half the window to a single loss event and take many RTTs to climb back.
- The slowest hop wins. Your 10 Gbps NIC is irrelevant if the path crosses a saturated uplink, a rate-limited API gateway, or a disk that only reads at 90 MB/s.
Rules of thumb I use: 90-95% for wired LAN and same-region cloud, 85% for a healthy wired WAN, 60-70% for Wi-Fi and mobile, 40-60% for a single TCP stream between continents — and back up toward 90% if you parallelise the transfer.
Bandwidth, throughput, latency
Three numbers, constantly confused, fixed by three different things.
| Bandwidth | Throughput | Latency | |
|---|---|---|---|
| What it is | Max capacity of the link | Bytes actually delivered | Delay for one round trip |
| Unit | Mbps / Gbps (quoted) | Mbps or MB/s (measured) | Milliseconds |
| Set by | Your plan and the slowest hop | Overhead, loss, windows, congestion | Distance, hops, queueing |
| Fixed by | Buying a fatter link | Parallel streams, tuning, compression | Getting closer: CDN, edge, region |
| In this tool | The link speed field | Link speed × efficiency | Hidden inside the efficiency % |
This calculator sizes the transfer. It cannot tell you whether the fix is a fatter pipe, more parallel streams, or a shorter path — that depends on which of the three is actually binding. Useful test: if raising the efficiency percentage alone gets you to a duration you would accept, your problem is protocol and tuning, not capacity, and buying more bandwidth is money set on fire.
When this estimate lies
Skip it when the payload compresses — a Postgres dump over ssh -C moves several times faster than its on-disk size suggests. Skip it when
the job is millions of small files, because you are bound by per-file syscalls
and round trips rather than bytes. Skip it when the real bottleneck is the
disk at either end. And nothing here models a transfer that dies at 80% and
restarts, which in practice is the actual reason the six-hour copy took two
days.
Questions people ask.
How long does it take to transfer 1 TB?
On a 1 Gbps link at 85% efficiency, 1 TB (decimal, 10^12 bytes) takes about 2 hours 37 minutes. On 100 Mbps that becomes roughly 1 day 2 hours. At 10 Gbps inside a datacenter it drops to about 16 minutes. The link rate is the headline, but the efficiency figure is what separates the estimate from the number you actually watch tick by.
Is 100 Mbps the same as 100 MB/s?
No — 100 Mbps is 12.5 MB/s. Mbps is megabits per second, MB/s is megabytes per second, and one byte is eight bits. Divide any bits-per-second figure by 8 to get bytes per second. This one conversion is behind most complaints that a connection runs eight times slower than advertised.
Why is my download slower than the speed I pay for?
Because the plan quotes line rate and you are measuring goodput. Protocol headers eat 5-6%, a single TCP connection is capped at receive window divided by round-trip time, congestion control spends the first seconds ramping up, and any hop on the path can be slower than your last mile. Getting 80-90% of the advertised rate on a wired link is a good day; Wi-Fi and mobile land closer to 60-70%.
Should I use 1000 or 1024 bytes per KB?
Use 1000 when the number came from a drive vendor, a cloud storage bill, or an object-store API. Use 1024 when it came from ls -lh, du, or Windows Explorer. The gap compounds with scale: 2.4% at the kilobyte, 9.95% at the terabyte. This calculator makes you pick a base instead of guessing, and prints the exact byte count next to the result so you can check the assumption.
What efficiency percentage should I use?
90-95% for a wired LAN or same-region cloud traffic, 85% for a healthy wired WAN, 60-70% for Wi-Fi or 5G, and 40-60% for a single TCP stream between continents. Parallel transfers — S3 multipart, rclone with several transfers, a few concurrent rsync jobs — push a long-haul link back toward 85-90%, because they route around the per-connection window ceiling.
Does this calculator upload my file or send my numbers anywhere?
No. There is no file picker and no network request. You type a size and a rate, and the arithmetic runs in JavaScript inside your tab. The page keeps working with the network switched off once it has loaded, and nothing is logged, stored, or transmitted.