Convert Mbps to MB/s, decimal to binary units, and get real transfer times.
This data transfer calculator answers the question every sysadmin ends up redoing by hand: how long will this transfer actually take, and why is my shiny 300 Mbps line only moving about 35 MB a second? Enter a file or dataset size and a link speed, and it gives you a realistic transfer time that accounts for protocol overhead, alongside bars comparing common links from a home fibre line to 10-gig. It also converts the units that quietly trip everyone up, bits versus bytes (Mbps versus MB/s) and the decimal-versus-binary gap (GB versus GiB), the same confusion that wrecks a capacity plan or makes a backup window look twice as comfortable as it really is.
100% in your browser. Nothing you type ever leaves this page.
- Effective throughput
- 35.2 MB/s
- Same speed in bits
- 282 Mbps
- Finishes at
The same transfer on other links
Unit converter
Decimal units (KB, MB, GB) are powers of 1000, what drive makers and ISPs sell. Binary units (KiB, MiB, GiB) are powers of 1024, what your OS often reports. The gap reaches 9.95% at the TB scale.
Self-test passed: conversions and transfer math verified against reference values on load.
Divide by eight, then take the haircut
Links are sold in bits per second. Files are measured in bytes. The industry has politely declined to fix that for forty years, and it’s the single most common reason a transfer looks broken when it’s behaving perfectly.
Divide by eight. A 300 Mbps line moves at most 37.5 MB per second, and once Ethernet, IP and TCP have taken their headers you’re realistically looking at 34 to 35. That one division explains most of the "my internet is slower than advertised" tickets ever raised. The calculator does the division for you, and applies an honest overhead haircut instead of quoting a theoretical ceiling nobody ever reaches. Both spellings sit side by side, so nobody is doing mental arithmetic in the middle of an incident.
The second unit trap sits one layer up. A 1 TB drive holds 1,000 GB if you ask the manufacturer and 931 GiB if you ask your operating system, because one counts in powers of ten and the other in powers of two. Nothing is missing and nobody is lying. Windows just labels gibibytes as "GB" and always has. We show both, because a migration estimate that mixes the two silently drifts by seven percent, and seven percent of a weekend window is a couple of hours you didn’t plan for.
Why your transfer is slower than this says
The number here’s a floor. It assumes the link is your bottleneck and the data streams continuously, and three things break that assumption on a daily basis.
Small files are the worst offender by a distance. A million 50 KB files move dramatically slower than one 50 GB archive, because every file pays for its own protocol handshake and filesystem metadata round trip. The link sits idle between them. Archive first, then move the archive, and the same job can finish in a fraction of the time.
Then there’s the disk at each end. A 10 Gbps LAN can’t outrun a source array that reads at 110 MB per second, and it’s remarkable how often the network gets blamed for a storage limit. Check what the source can actually sustain before you size the pipe.
Latency is the subtle one, and it’s why a fat transatlantic link can crawl. TCP will only keep as much data in flight as the receive window allows, so on a 100 ms round trip an unscaled 64 KB window caps you at roughly 5 Mbps no matter what you paid for. Window scaling fixes it and has been on by default for years, but middleboxes still clamp it, and long fat links are exactly where that shows up. If a transfer badly underperforms the estimate, the answer is nearly always in one of these three places rather than in the cable.
Planning a migration with it
This is what most people actually came for, so let’s do the arithmetic out loud. Two terabytes over a 300 Mbps office line, at a realistic 34 MB per second, is about sixteen hours. That fits a weekend. It doesn’t fit a maintenance window, and it certainly doesn’t fit if the office is also using the line, which it will be.
So the useful questions are about windows rather than speeds. Does the copy fit in the outage you’re allowed? If not, can you seed most of it in advance and sync only the delta at cutover, which is what almost every successful migration ends up doing? And at what point does the maths stop working entirely?
Our rough line is around ten terabytes on a typical business connection. Past that, shipping physical disks genuinely beats the wire, and a courier has a bandwidth that would embarrass any link you can buy. It feels primitive right up until you compare the numbers. Run both estimates before committing to a plan, because the wrong choice here’s measured in days.
Frequently asked questions
How long will it take to transfer my data?
Enter the size and the link speed above and the answer appears immediately, with the bits to bytes conversion and a realistic overhead allowance already applied. Treat it as a floor rather than a promise. Many small files, a slow disk at either end, or a high latency path will all push the real figure up, sometimes by a lot.
Why is my download slower than my advertised speed?
Usually because you’re comparing bits to bytes. A 300 Mbps connection tops out around 37.5 MB per second before overhead and roughly 34 after it, so a browser reporting 34 MB/s is delivering exactly what you pay for. If the gap is much wider than that, look at the far end rather than your own line, since a single server rarely saturates a modern connection on its own.
What is the difference between GB and GiB?
A gigabyte is 1,000,000,000 bytes and a gibibyte is 1,073,741,824, about seven percent more. Storage is sold in the decimal unit and operating systems mostly report the binary one while still writing "GB", which is where the missing capacity on a new drive comes from. Over a terabyte the gap reaches 69 GB, enough to matter when you’re sizing a migration window.
Does latency affect transfer speed?
Yes, and more than people expect. TCP keeps a limited amount of data in flight, bounded by the receive window, so throughput is roughly that window divided by the round trip time. On a 100 ms path an unscaled 64 KB window works out at about 5 Mbps regardless of the capacity underneath. Window scaling raises the ceiling, but a middlebox that strips or clamps it will quietly hold a long distance transfer at a fraction of the link speed.
Is it faster to ship disks than to transfer over the network?
Past roughly ten terabytes on a normal business line, usually yes. Sixteen hours for two terabytes is tolerable; a hundred terabytes on the same connection is a month of continuous copying with no margin for a failure halfway through. Work out the wire time here first, then compare it with a courier and a couple of drives. The answer is often less dignified and much faster.