File Transfer Time Calculator for Any Bandwidth

Time = file size in bits / bandwidth in bits per second. A 1 GB file (8 × 10^9 bits using decimal gigabytes) over a 100 Mbps link takes 80 seconds at theoretical peak. The calculator handles the unit conversion: gigabytes to bits, megabits/second to bits/second. The number it returns is the floor. Real transfers take longer due to overhead and ramp-up, which the next several FAQs cover.

Three things eat into the gap. Protocol overhead (TCP/IP headers, TLS handshakes, application framing like HTTP, SMB, SCP) takes 5 to 15% of every byte on the wire. TCP slow-start ramps the congestion window over the first 5 to 10 round trips, so transfers under a few MB never hit steady state. ISP shaping or QoS policies cap many "1 Gbps" residential connections at 50 to 80% of rated speed during peak hours. Apply a 70 to 90% efficiency factor to the calculator's output for a realistic estimate.

Mbps is megabits per second (lowercase b). MB/s is megabytes per second (uppercase B). Eight bits make a byte, so 100 Mbps = 12.5 MB/s. ISPs advertise in bits because the number is bigger and sounds faster. "100 Mbps" markets better than "12.5 MB/s." Download managers display in bytes because that's what users actually care about, since file sizes are in megabytes. The calculator supports both. Just be careful which unit you pick from the dropdown.

MB is decimal: 1,000,000 bytes. MiB is binary: 1,048,576 bytes. The 4.86% gap compounds at the gigabyte and terabyte scales. A 2 TB drive (decimal, what manufacturers ship) is only 1.82 TiB once your OS reports it (binary, what Windows and most Linux file managers show). For transfer math, decimal MB is the convention because bandwidth is decimal. It's a "consistent units" rule, not a "right answer" rule. Mixing the two is how transfer estimates get systematically wrong by about 5%.

Heavily depends on the content type. Plain text and source code: 70 to 90% reduction with gzip or zstd. Office documents: 50 to 70% (they're already lightly compressed internally). JPEG, PNG, and video files: 0 to 5%, since they're already compressed and re-compressing wastes CPU. Database dumps: 60 to 85% if they're SQL, less if they're binary. The rule of thumb: compress text-heavy archives, skip compression for media. For backup pipelines, zstd is a better default than gzip in 2026: same compression ratio, faster decompression.

Most consumer internet is asymmetric. Cable and DSL provisioning historically assumed users consume more than they produce. A 100/10 plan gives 100 Mbps down and 10 Mbps up. Fiber is symmetric on most plans (1 Gbps both ways), but residential DOCSIS still leans 10:1 or 20:1 asymmetric. The calculator lets you set the direction. The math itself is identical, just the bandwidth number changes. For business connections that need to upload large datasets reliably, dedicated symmetric circuits are usually worth the price difference.

A few usual culprits. The advertised bandwidth was conservative, since many ISPs deliver above their rated speed during off-peak hours. The transfer compressed at the protocol layer (some HTTP servers gzip on the fly, SCP can compress with -C). Or you weren't actually transferring as much data as the file size suggested. Sparse files, deduplicated storage, and rsync's delta transfer can move far less than the file's apparent size. If the gap is consistent and large, it's worth checking which one applies before assuming the calculator is wrong.

As a ceiling, yes. As a typical, no. ISP-run speed tests use carefully placed servers and prioritized traffic, and they show you what the link can do under ideal conditions. A real transfer to a remote endpoint will hit at least one of: shared upstream congestion at peer interconnects, the destination server's egress limits, or routing over a path with higher latency than the speed test server. For planning, take the speed test number and apply a 60 to 80% efficiency factor for general internet transfers, 80 to 95% for transfers within the same metro or to a major cloud region.

TCP slow-start. Every new connection starts with a small congestion window (typically 10 segments or about 14 KB) and doubles it every round trip until it hits the link's capacity or starts losing packets. For a 50 KB file over a 1 Gbps link, the connection finishes before it even reaches steady-state speed, so you see effective throughput of maybe 20 Mbps. This is why transferring 10,000 small files is much slower than transferring one 500 MB tarball even though the total bytes are similar. Packing small files before transfer is the standard fix.

Calculate the steady-state transfer time at 50% of rated bandwidth, not 90%. Backup jobs hit during periods when other traffic is also spiking, like overnight cron jobs, monitoring rollups, and log shipping. Sizing for 90% of rated bandwidth means your backup contends with everything else and starts running long. Sizing for 50% gives the backup deterministic completion. If your backup window is 6 hours and the calculator says it'll finish in 4 hours at 50% bandwidth, you've got margin. If it says 5h 45m at 50%, increase the link.

50 to 70% for cross-continent transfers (US to Europe, US to Asia) on a single TCP flow. The bandwidth-delay product caps single-flow throughput at roughly bandwidth × RTT bytes. A 1 Gbps link with 150 ms RTT to Europe maxes a single connection at about 18 MB. Multi-stream tools (aspera, rclone with parallel transfers, parallel rsync) work around this by opening multiple connections and getting closer to the link's true capacity. If you're moving multi-terabyte datasets across the WAN single-stream, the calculator's estimate will be wrong by a factor of 5 to 10.

Real-world transfers rarely hit theoretical bandwidth. TCP slow-start ramps the window over the first several round trips. The bandwidth-delay product caps single-flow throughput on long-distance links. Disk I/O and protocol overhead (TLS, SMB, FTP framing) take 5 to 15%. ISP shaping or QoS policies cap many "1 Gbps" connections at 50 to 80% of rated speed during peak hours. For transfers over 10 GB across WAN links, multiply the calculator's estimate by 1.3 to 1.8x to set a realistic expectation. For LAN transfers, 1.1 to 1.2x is usually enough.