Bandwidth & Transfer Time Calculator

Why your "100 Mbps" connection moves at 12 MB/s

Internet speeds are sold in bits per second. File sizes are in bytes. One byte = 8 bits. So 100 Mbps ≈ 12.5 MB/s in theory, ~10–11 MB/s in practice after TCP overhead, retransmits, and the gentle dishonesty of marketing.

The "efficiency" slider on the calculator above lets you set realistic expectations. Defaults to 85%, which is reasonable for direct wired transfers; drop to 50–65% for typical home WiFi.

How to actually estimate transfer times

Every time a customer asks "how long will it take to move X gigabytes to Y," the answer is almost never the number you get from dividing size by link speed. Real-world transfers involve overhead, contention, congestion, and a bunch of other factors that reduce the theoretical maximum to something quite a bit lower. Understanding what causes the gap between advertised speed and actual throughput saves a lot of "why is this slower than it should be" conversations.

Bits versus bytes: the confusion tax

Network speeds are quoted in bits per second. Storage sizes are quoted in bytes. A byte is 8 bits, so a 100 megabit-per-second link theoretically carries 12.5 megabytes per second. That factor of 8 catches almost everyone the first time they run into it. When your ISP advertises 100 Mbps and your download shows 12 MB/s in the browser, that's the maximum you should expect — the numbers are just written in different units.

ISPs and networking vendors use bits per second because that's how the underlying signaling works at layer 1 and layer 2. Storage vendors use bytes because that's how files are measured. Both are correct within their domain; the confusion comes from mixing them.

Protocol overhead: the 5-15% you never see

Every packet on the wire carries headers. An Ethernet frame has 14 bytes of Ethernet header. Inside that, an IPv4 packet has at minimum 20 bytes of IP header. Inside that, a TCP packet has at minimum 20 more bytes. HTTPS traffic adds a TLS record header on top. So a 1500-byte MTU frame carrying TCP payload has 54 bytes of overhead just from headers, leaving 1446 bytes for actual data — about 96% efficiency at the packet level.

But that's only the framing overhead. TCP itself has acknowledgment traffic flowing in the reverse direction, and each ACK is a small packet with its own headers. Retransmissions when packets are lost. Window scaling adjustments. HTTPS handshakes at the start of each connection. Between all of these, real-world useful throughput on a well-behaved connection is often 88-93% of the theoretical line rate. On a busy network with some packet loss, it drops further.

The receiving side matters as much as the sending side

A transfer completes when both endpoints agree it's done. If the sender has a 1 Gbps uplink but the receiver has a 100 Mbps downlink, the transfer runs at 100 Mbps. Bandwidth is the minimum of every link along the path — a chain is only as fast as its slowest hop.

This shows up constantly with cloud backup services. A customer with a 1 Gbps fiber connection wonders why their backup to Backblaze is running at 50 Mbps. Turns out Backblaze's per-connection cap, plus the local machine's disk write speed, plus the CPU overhead of encryption, all combine to well below the network link speed. The network isn't the bottleneck — something else in the chain is.

Single-stream versus multi-stream transfers

TCP has a mechanism called congestion control that limits how much data can be in flight at any moment. On a long-distance connection with high latency, a single TCP stream can be bottlenecked by this — even if there's plenty of unused bandwidth on the physical link. This is why speed test tools open multiple parallel connections. Ten streams together can saturate a link that any single stream can't.

The same effect shows up in real-world transfers. A single-file rsync to a distant server might run at 20 Mbps on a 100 Mbps link because TCP's window sizing keeps it capped. Running multiple parallel rsync jobs — or using a tool like Aspera or Rclone with parallel-transfer flags — pushes the aggregate closer to link speed.

What "how long will this take" really means

The formula the tool uses is straightforward: divide the total transfer size by the effective bandwidth. But which bandwidth number you use makes all the difference.

If you plug in the theoretical link speed (100 Mbps for a 100 Mbps connection), you'll get an answer that's optimistic by 10-30%. If you plug in the number you get from a speed test, you'll be closer to reality but still slightly optimistic because speed tests measure best-case scenarios with parallel streams and CDN-hosted servers. If you plug in a realistic sustained rate from actual measurement of the specific transfer you're planning (say, 75 Mbps for a residential fiber connection doing a real cloud backup), you'll be closest to correct.

The tool defaults to using an "efficiency factor" that accounts for typical overhead. If you leave it at 85%, that's a reasonable default for internet transfers over TCP. For LAN transfers where there's less congestion and often no encryption, 95%+ is achievable. For satellite links or heavily-loaded shared connections, 60-70% might be more realistic.

Where I use this in real work

Planning cloud migrations

Moving a 5 TB dataset from an on-premises NAS to Backblaze B2 or AWS S3 is a common request. The customer wants to know "how long will it take" so they can plan around it. Naive math with the link speed gives a wildly optimistic answer. Realistic math with actual sustained throughput gives an answer you can plan a maintenance window around.

For a small business on a 200 Mbps symmetric fiber connection, transferring 5 TB with 85% efficiency gets you about 60 hours of continuous transfer time — two and a half days. That's actually planable. The naive math (5 TB / 200 Mbps at 100% efficiency = 55 hours) is close, but if you use the connection during business hours the real elapsed time can double or triple.

Sizing backup windows

Nightly offsite backups have to fit in the window between end-of-business and start-of-business. If your daily changed data is 50 GB and your uplink is 20 Mbps, that's about 6 hours at 100% efficiency, or 7 hours at 85%. If your maintenance window is 8 hours, you're fine. If it's 5, you have a problem to solve — either faster upload, incremental changes, deduplication, or moving to a longer window.

Estimating remote-work bandwidth needs

Video conferencing uses about 1-3 Mbps per participant depending on quality. Screen sharing adds another 1-2 Mbps. Remote desktop sessions (RDP, VNC, Parsec) can range from a few hundred kbps for basic office work to 20+ Mbps for CAD or design work. If a company has 20 people working from home over a shared VPN, the aggregate can push a 100 Mbps circuit hard during peak hours.

Video streaming quality decisions

4K streaming needs about 25 Mbps sustained. 1080p is more like 5-8 Mbps. If you're on a rural cellular connection with 15 Mbps down, 4K just isn't going to work reliably even if it starts fine. Setting the streaming service to 1080p up front produces a much better experience than watching buffer wheels every ten minutes.

Common misconceptions

"My connection is 100 Mbps but I only get 90 Mbps on speed tests"

This is normal. 90 Mbps is 90% of your link, which is well within the expected efficiency range. Getting more than 95% of your rated speed on a real speed test is unusual and usually only happens if you're very close to your speed test server.

"Why is my upload slower than my download?"

Most residential internet connections are asymmetric — a lot more download bandwidth than upload. Cable and DSL both do this intentionally because most residential use cases are heavily download-biased. Fiber connections are often symmetric (equal upload and download), but not always. If your upload is 10% of your download on a cable connection, that's by design, not a fault.

"I'm paying for 500 Mbps but Speedtest.net shows 350"

Speedtest.net measures to servers hosted at ISPs, which is a shorter path than most real internet destinations. If Speedtest.net shows lower than your rated speed, that's a sign of either congestion at your ISP or a problem in your home network. If the tool on this site (which measures to Cloudflare's edge) shows even lower, that's typical because the path is longer.

Related tools

The Speed Test measures actual throughput to Cloudflare's edge network, which is a good proxy for real-world browsing and streaming performance. Combine the two: measure your actual throughput with the speed test, then use that number in the bandwidth calculator to get realistic transfer time estimates.

If you're planning around VoIP quality, the VoIP Test measures latency, jitter, and packet loss — which matter more than raw bandwidth for real-time voice traffic. And if you're troubleshooting MTU-related transfer problems (fragmentation slowing things down), the MTU / MSS Calculator can help identify whether your path MTU is smaller than it should be.