How long to download 20 GB at 25 Mbps

Six thousand four hundred seconds, and the four numbers behind it

Bits, bytes and the 3.125 MB/s meter

Twenty decimal gigabytes is 20,000 MB, and at eight bits to a byte that is 160,000 megabits. A 25 Mbps line moves 25,000,000 bits every second, so 160,000,000,000 / 25,000,000 = 6,400 seconds. That is 1 hour 46 minutes 40 seconds, and no idle line of this size beats it.

Switch to bytes and the figure becomes something you can watch. Twenty five megabits a second is 25 / 8 = 3.125 MB/s, so 20,000 / 3.125 = 6,400. Every minute adds 187.5 MB, every hour adds 11.25 GB, and the bar covers 56.25 percent of the file in an hour. That last number explains the shape of the wait: the first quarter is gone in 26 minutes 40 seconds, and the final quarter feels longer than the first three together.

Cost per gigabyte is the figure to carry around: 8,000 / 25 = 320 seconds, which is 5 minutes 20 seconds. Double the payload and the wait doubles; halve the rate and it doubles again. A 50 GB package on this line needs 16,000 seconds, 4 hours 26 minutes 40 seconds. A 200 GB one needs 64,000 seconds, 17 hours 46 minutes 40 seconds, which is a weekend rather than an afternoon.

Real traffic carries framing, acknowledgements and the odd retransmission, so the rated clock is a floor. Six percent of overhead turns 6,400 into 6,784 seconds, 1 hour 53 minutes 4 seconds. Twelve percent gives 7,168 seconds, 1 hour 59 minutes 28 seconds. Budget for the overhead figure and the arrival of the last byte stops being a surprise.

The number on the router box is not the number at the sofa

What a 60 percent airlink does to 6,400 seconds

A 25 Mbps plan is often limited by the last few metres rather than by the provider. A 2.4 GHz link sharing a channel with four neighbours, or a 5 GHz link at the far end of a flat, delivers somewhere between 40 and 90 percent of the rate the router negotiates. The download does not care where the loss comes from. It only sees the lower number.

At 88 percent of the label the line behaves like 22 Mbps and the clock reads 2 hours 1 minute 13 seconds, 14 minutes 33 seconds later than the wired figure. At 60 percent it reads 2 hours 57 minutes 47 seconds. At 40 percent the transfer needs 4 hours 26 minutes 40 seconds, which is exactly what a wired 10 Mbps line would give you for the same file.

Distance and walls are the usual culprits, and so is the band. A 2.4 GHz signal travels further through brick but shares three non-overlapping channels with everyone on the street. A 5 GHz signal is cleaner at close range and falls off sharply through two walls. On a plan this size, either band can carry the file when the device sits in the same room as the router, and neither can promise it from a back bedroom.

One cable settles the question. A single Ethernet run costs less than a month of the subscription, removes the radio from the path, and turns a two hour job back into a one hour forty seven minute one. Where drilling is not an option, a powerline adapter or a mesh node with a wired backhaul is the next best thing, because the weak hop then sits between two fixed points instead of between the router and a laptop that moves.

A 1080p stream takes a fifth of the pipe and adds 26 minutes

Netflix's 5 Mbps figure applied to a 25 Mbps plan

Netflix publishes the connection it wants for each picture quality: 3 Mbps for 720p, 5 Mbps for 1080p and 15 Mbps for 4K (Netflix, help page checked November 2026). On a 25 Mbps line that 1080p figure is a fifth of the pipe, and the share is what matters, not the absolute number.

One stream leaves 20 Mbps, so the file needs 8,000 seconds, 2 hours 13 minutes 20 seconds, and 26 minutes 40 seconds are gone. Two streams leave 15 Mbps and the transfer stretches to 2 hours 57 minutes 47 seconds. Three leave 10 Mbps and it runs 4 hours 26 minutes 40 seconds, the same as unplugging the router and using a 10 Mbps line. Four streams leave 5 Mbps, which is 8 hours 53 minutes 20 seconds. A fifth stream fills the line and the download stalls rather than slows.

A video call is cheaper than a stream. The FCC's consumer speed guide puts an HD personal call at 1.5 Mbps and HD video conferencing at 6 Mbps (FCC, guide reviewed 2026), so a call costs between 6 and 34 minutes of download time. At 1.5 Mbps the line keeps 23.5 Mbps and the file lands after 1 hour 53 minutes 29 seconds. At 6 Mbps it keeps 19 Mbps and lands after 2 hours 20 minutes 21 seconds.

Queueing makes the picture worse than the arithmetic suggests. When the line is full, a router holds packets in a buffer, video keeps its share and the file waits, so a page load during the transfer feels broken even though the file is moving. Capping the download client at 20 Mbps is the one lever a subscriber controls, and it costs 26 minutes 40 seconds while keeping the evening usable.

Quarter marks on a one hour forty seven minute bar

What to expect between 1:00 pm and 2:46:40 pm

A progress bar is a poor stopwatch and a decent calendar. Divide 6,400 seconds by four and each quarter is 1,600 seconds, 26 minutes 40 seconds. Start at 1:00 pm and a quarter is done at 1:26:40, half at 1:53:20, three quarters at 2:20:00, and the last byte arrives at 2:46:40.

The remaining-time label is calculated from the last few seconds, so it swings by half an hour whenever the far server pauses to flush a buffer. Judge progress by bytes instead. A client holding 3.1 MB/s for ten minutes has moved 1,860 MB, which is 9.3 percent of the file, and that is ahead of schedule. A client showing 2.5 MB/s for the same ten minutes has moved 1,500 MB, 7.5 percent, and the finish has slipped to about 2 hours 13 minutes.

The shape of the curve is worth knowing for a scheduled job. Windows and macOS both slow the transfer when the screen locks on battery, and both may start an update at the worst possible moment. Setting the machine to stay awake for the length of the transfer costs about 26.7 watt hours at 15 W, which is a tenth of a small laptop battery and far less than restarting a job that died at 80 percent.

A power cut at 70 percent costs 32 minutes, not the afternoon

Range requests and the price of starting over

Losing power late in a transfer is cheap if the client can resume. Range requests, standardised in RFC 9110 (IETF, 2022), let a client ask a server for bytes from a given offset instead of from zero, and most file hosts answer them. A session that dies at 70 percent leaves 6,000 MB, which is 1,920 seconds or 32 minutes at this rate.

Not every host cooperates. A signed URL that expires after an hour breaks a one hour forty seven minute job by design, and a script that writes to a temporary file and deletes it on failure cannot resume at all. Browsers vary: some keep a partial file and offer a retry, others start again from zero without saying so. A download manager that shows the byte count is the only reliable way to know which one you have.

Integrity matters more than resume on a link of this size. A file assembled from two sessions can be corrupt if the host rebuilt the package between them, and a 20 GB archive is not something you want to discover is bad after 6,400 seconds. Check the published hash when the file lands. On a slow line the checksum is the cheapest insurance available, and it takes a few seconds against a two hour wait.

Twenty gigabytes is a fifth of a 100 GB allowance

Caps, share of the month, and the files that still fit

On a metered connection the file has a second cost beyond time. A 100 GB monthly allowance gives up a fifth of itself to one 20 GB download and leaves 80 GB for everything else. A 50 GB allowance gives up 40 percent and leaves 30 GB, which is a thin month if the same file arrives twice.

Ten files of this size in a month is 200 GB, and that is where a 200 GB allowance stops being comfortable. The arithmetic is unforgiving because the download is only one of several consumers: a 4K set, cloud photo backup and a games console all draw from the same pool, and the console can pull 50 GB in an evening without anyone noticing.

Two habits keep the month intact. Move large transfers to the start of a billing cycle rather than the end, when a surprise overage has no time to be absorbed. And check whether the provider counts uploads, since a backup that pushes 20 GB uphill spends the allowance twice if the file also arrived over the same connection.

Ten, twenty five, fifty: the clock halves at every step

Where the 25 Mbps tier sits between its neighbours

Doubling the line halves the wait, which makes the tier ladder easy to read. On the same 20 GB file, 10 Mbps needs 4 hours 26 minutes 40 seconds, 25 Mbps needs 1 hour 46 minutes 40 seconds, 50 Mbps needs 53 minutes 20 seconds and 100 Mbps needs 26 minutes 40 seconds.

The step from 10 to 25 saves 2 hours 40 minutes, the largest gain in the table. The step from 25 to 50 saves another 53 minutes 20 seconds, and the step from 50 to 100 saves only 26 minutes 40 seconds. Each upgrade buys less absolute time than the one before it, because the job is already short enough that the remaining wait is a coffee break rather than an afternoon.

Below this tier the curve turns brutal. At 5 Mbps the same file takes 8 hours 53 minutes 20 seconds, and at 3 Mbps it takes 14 hours 48 minutes 53 seconds, which is a working day for a file that would fit on a thumb drive. That asymmetry is why a 25 Mbps plan feels like a threshold: above it, most single-file jobs finish inside a session of use. Below it, they shape the day.

A 25/3 plan sends the same file uphill for fifteen hours

Upload symmetry and the backup that never finishes

Most 25 Mbps residential plans in the United States are asymmetric, with 3 Mbps of upload against 25 Mbps of download. That ratio is invisible in a web browser and obvious the moment a 20 GB file has to leave the house. At 3 Mbps the same payload needs 53,333 seconds, 14 hours 48 minutes 53 seconds, more than eight times the download clock.

This is why a photo library of 20 GB takes a night to seed to a cloud service and a game of the same size installs over lunch. The plan was sold on the download figure, and the download figure is the one that never applies to a backup.

Practical workarounds are few. Cap the backup client so it does not saturate the 3 Mbps uplink, because a saturated uplink adds latency to every call and page load in the house. Seed the first copy from a local drive, since most services accept a mailed disk for the initial upload. And run the seeding overnight, when a fifteen hour job has somewhere to sit.