How long to download 20 GB at 50 Mbps

Fifty three minutes and twenty seconds, derived in one pass

Where 6.25 MB/s comes from and why it needs no rounding

Start with the payload in megabits. Twenty decimal gigabytes is 20,000 MB, and eight bits to a byte makes that 160,000 megabits. Divide by 50 and the result is 3,200 seconds, which is 53 minutes 20 seconds, or 0.889 of an hour. Every step divides cleanly, which is why a 50 Mbps line produces such tidy numbers.

In bytes the meter sits at 50 / 8 = 6.25 MB/s. A minute of that moves 375 MB, an hour moves 22.5 GB, and one gigabyte costs 160 seconds. Scale it: 5 GB needs 800 seconds, 50 GB needs 8,000 seconds, 200 GB needs 32,000 seconds. Nothing about the file type changes the arithmetic, only the size.

Overhead is small here but not zero. Three percent, a fair figure on a clean TCP connection, gives 3,296 seconds, 54 minutes 56 seconds. Six percent gives 3,392 seconds, 56 minutes 32 seconds. Both stay under the hour, and staying under the hour is the sentence that decides whether you start the transfer now or leave it for later.

An hour that fits between two meetings

Quarter marks and the latest start that still ends on time

Fifty three minutes is short enough to schedule around other things, which changes how you plan it. The four marks fall at 800, 1,600, 2,400 and 3,200 seconds: 13 minutes 20 seconds, 26 minutes 40 seconds, 40 minutes and 53 minutes 20 seconds of elapsed time.

Working backwards is the useful direction. A call that starts at 2:00 pm means pressing the button by 1:06:40 pm, because 53 minutes 20 seconds before two o'clock is 1:06:40. A file needed for a 9:00 am meeting has to be finished, verified and copied by then, so the realistic start is 8:45 am with a ten minute buffer for the hash check.

Countdown labels drift on a short job more than they do on a long one, since a two second stall eats a larger share of the estimate. Watch the byte counter instead: six minutes at 6.0 MB/s moves 2,160 MB, about a tenth of the file, and the finish has slipped by 2 minutes 13 seconds against the rated pace.

One 4K stream costs you 22 minutes 51 seconds

Two published 4K figures and what each does to the finish

Netflix asks for 15 Mbps to deliver 4K (Netflix, help page checked November 2026), while the FCC's consumer guide lists 25 Mbps for Ultra HD (FCC, guide reviewed 2026). The two figures bracket real behaviour: one set with a deep buffer holds up at 15, a household with three sets wants the higher number.

At 15 Mbps a single 4K stream takes 30 percent of a 50 Mbps line. The transfer drops to 35 Mbps and finishes in 1 hour 16 minutes 11 seconds, 22 minutes 51 seconds later than an empty line. Two streams leave 20 Mbps and the finish moves to 2 hours 13 minutes 20 seconds, two and a half times the baseline. Three streams leave 5 Mbps and the file crawls at a tenth of the speed it had.

At three streams the arithmetic stops being a nuisance. The file behaves like a 5 Mbps connection for two and a half hours, which is longer than the film that caused the problem. The honest move there is to schedule the transfer for after the house goes quiet, or to pause the download while the film runs and accept 53 minutes afterwards.

Most routers offer no per-device shaping, so a client-side cap is the lever you control. Capping the download at 30 Mbps leaves 20 for the television and gives a finish of 1 hour 28 minutes 53 seconds, which is the compromise most households settle on without naming it.

The speed test says 50 and the transfer moves at 44

Where the missing six megabits go

A speed test reports the best second it can find, usually against a server a few hundred kilometres away, with several parallel streams running at once. A file transfer gets one connection, a host that may be on another continent, and a disk at the far end that has to accept the bytes. Ninety two percent of the label is a good day. Eighty eight percent is an ordinary one.

The gap between 96 and 88 percent is 5 minutes 3 seconds, which is small enough that chasing it for one file is not worth an evening. On recurring work it compounds: two transfers a week at 88 percent instead of 96 percent costs 8.8 hours a year, and that is the sort of number that justifies a support call.

Three sources account for most of the loss. TCP slow start adds a few seconds at the beginning of every connection, which hurts a folder of small files far more than one archive. A distant origin adds round trips that no local setting shortens. And a saturated uplink, from a backup or a video call, adds latency that slows the download's acknowledgements even though the downstream direction has room.

Diagnosis is cheap. Watch the meter for thirty seconds with everything else idle. If it holds near 6.0 MB/s the line is doing its job and the rest is overhead. If it sits at 2 MB/s, try a second mirror before touching the router, because a server limit looks exactly like a line limit from the inside.

At 6.25 MB/s the disk keeps up, until it does not

Write paths measured against 53 minutes of line time

Twenty gigabytes arriving at 6.25 MB/s is a gentle load for storage. Any SSD and most spinning disks absorb it without breathing hard, so on a line this size the drive is rarely the reason a transfer feels slow. The exceptions are the cheap cards and the old flash drives, and they fail in a way that looks like a network fault.

Those figures are sustained sequential writes, which is the kindest case. A game package with 40,000 small assets writes in 4 KB chunks, and a flash drive that manages 35 MB/s in a straight line can fall to 2 MB/s in that pattern. Then the drive, not the line, sets the finish, and the symptom is a download that reports 6 MB/s while the progress bar moves at a third of that pace.

The other candidate is the far server, and on a 50 Mbps line it is the more common limit. A CDN edge close to you will saturate the connection. A university mirror on another continent will deliver 2 MB/s and apologise to nobody. If a transfer sits at 2 MB/s while a speed test reports 50, the queue is upstream, and changing mirrors is the only fix that costs nothing.

Five devices on one line, and the arithmetic of a shared house

Subtracting what everyone else is already using

Fifty megabits is a household resource, not a personal one, and the subtraction is direct. Whatever the television, the console and the phone call are using comes off the top before the file gets a share.

The table understates the damage, because a full line does not divide fairly. A router queues packets, video keeps its share through buffering, and the file waits at the back. Page loads during a saturated upstream feel broken even when the downstream has headroom, which is why an evening download and an evening of video calls do not coexist well on 50 Mbps.

Two arrangements work. Run the transfer first and stream later, since 53 minutes is short enough to fit before dinner. Or cap the client at 30 Mbps and accept 1 hour 28 minutes 53 seconds, which leaves enough for one 4K stream and keeps the house usable.

Fifty or one hundred: 26 minutes saved, or nothing at all

When the next tier up pays for itself

The FCC's 2024 Communications Marketplace Report puts the median residential download speed purchased in 2023 at 400 Mbps, up from 150 Mbps in 2020, with the tenth percentile at 25 Mbps (FCC, 2024). A 50 Mbps line is now below the median, which is worth knowing before deciding whether to upgrade.

One file a week, upgraded from 50 to 100 Mbps, saves 26 minutes 40 seconds a week, which is 23 hours a year. Ten files a week saves 231 hours, and at that volume the upgrade has already paid for itself in the first month. The break-even point is frequency, not file size.

Doubling to 100 Mbps does nothing when the server or the disk is the limit. A mirror delivering 2 MB/s leaves 87 Mbps of a 100 Mbps line unused, and a class 4 SD card caps the job at 1 hour 6 minutes 40 seconds no matter what the plan says. Check both before buying more speed, because the line is only one of three stages in the path.

Five numbers worth confirming before you walk away

Decimal against binary, overhead, and the sleep timer

Twenty gigabytes is a decimal figure. Windows reports the same download as 18.63 GiB, because it divides by 1,073,741,824 bytes, the binary unit that NIST keeps distinct from the decimal one (NIST, IEC 60027-2). The file has not grown. The unit changed, and the clock with it.

The binary reading is 235.97 seconds longer, under four minutes, which is small enough to ignore on this line and large enough to explain a mismatch between a file's advertised size and a folder's reported size. Settle which unit the source uses before dividing anything.

The sleep timer is the one setting that costs a whole transfer. A 30 minute idle sleep suspends the network stack long before 53 minutes elapse, and the job resumes at a lower rate while the radio renegotiates. A laptop pulling 15 W for 53 minutes 20 seconds uses 13.3 watt hours, so the transfer costs almost nothing to finish. Disable sleep for the hour, start the job, and check the hash when it lands.

The last check is free space. Twenty gigabytes needs 20 GB plus the temporary copy some clients keep, so 25 GB of headroom avoids a failure at 95 percent. On a line this fast the transfer is the short part, and the cleanup afterwards takes longer than the download did.