Download Time and File Size Calculator

A download time and file size calculator estimates how long a download or upload will take, converts file-size units, calculates the connection speed needed for a deadline, and shows how much data a connection can transfer within a selected period.

The calculation begins with the relationship between data size and transfer rate. Protocol headers, encryption, congestion, Wi-Fi interference, server limits, storage speed and competing traffic reduce real throughput. A useful estimate therefore separates theoretical and effective speed.

What the calculator can do

• estimate download or upload time for one file or a sequential queue;
• subtract the percentage that has already transferred;
• handle multiple copies of the same file;
• convert between bits, bytes, decimal units and binary units;
• apply an efficiency factor for protocol and network overhead;
• reserve only part of the connection for the transfer;
• show ideal, typical, fast and conservative completion estimates;
• calculate the connection speed required for a target time;
• calculate how much data can move during a selected period;
• estimate storage saved after compression;
• export file-level results to CSV.

The basic download-time formula

When the file size and connection rate use compatible units, the core formula is:

Transfer time = data size ÷ transfer speed.

Internet plans normally express speed in bits per second, while operating systems and applications often show file size in bytes. Convert the file to bits before dividing:

Transfer time in seconds = file size in bytes × 8 ÷ speed in bits per second.

The 80-second result describes an ideal link without losses or competing traffic. Most real transfers take longer.

Mbps and MB/s are not the same

The lowercase b means bit, while the uppercase B means byte. One byte contains eight bits:

1 B = 8 bit.

Therefore:

100 Mbps ÷ 8 = 12.5 MB/s.

A browser that reports 10.6 MB/s on a 100 Mbps connection moves about 84.8 Mbps of application data, which can be normal after overhead.

Decimal SI and binary IEC units

Decimal prefixes use powers of 1000. Binary prefixes use powers of 1024. NIST and IEC distinguish these systems clearly:

Storage manufacturers and network providers usually use decimal units. Some operating systems and technical tools use binary quantities, sometimes while displaying familiar decimal labels. The calculator offers both SI and IEC modes so the user can match the source.

Why actual transfer speed falls below the advertised rate

Applications do not place only file content on the network. TCP, IP, Ethernet, Wi-Fi, TLS and application protocols add control information. Reliable transports also detect loss, acknowledge data and adjust their sending rate when congestion appears. TCP defines reliable, ordered delivery, while QUIC includes flow control, loss recovery, congestion control and encryption.

The calculator models these effects with a network-efficiency percentage. An efficiency of 85% means that the application receives an estimated 85% of the selected connection rate:

Effective speed = advertised speed × efficiency.

No single efficiency value fits every network. A clean wired connection may perform better, while distant servers, busy Wi-Fi, VPNs or lossy mobile links may perform worse.

Available bandwidth and other traffic

A household or office rarely dedicates the whole connection to one transfer. Video calls, streaming, cloud backups, game updates and other users consume part of the bandwidth. The calculator therefore includes an available-bandwidth percentage:

Transfer speed = connection speed × efficiency × available bandwidth.

Speed fluctuation and completion windows

Throughput changes during a transfer. Congestion control reacts to packet loss and delay, wireless quality changes, and remote services may throttle traffic. Instead of hiding this uncertainty, the calculator uses a fluctuation percentage to produce a fast and conservative estimate.

With an effective rate of 85 Mbps and a ±15% range, the calculator compares approximately 97.75 Mbps with 72.25 Mbps. The resulting finish-time window gives a more honest planning range than a single timestamp.

Multiple files and sequential queues

A queue often contains many files rather than one archive. The calculator adds each file’s remaining data and applies an optional setup delay for every item. The delay can represent a new request, authentication step, filesystem operation or application pause.

Total delay = initial delay + number of files × delay per file.

For a sequential queue, the tool also estimates when each file will finish. Quantity multiplies the file size, while the completed percentage reduces only the remaining transfer.

Resume progress and remaining size

A resumed download should not use the original file size as the remaining workload. The calculator applies:

Remaining data = total data × (1 − completed percentage ÷ 100).

A 40 GB game update at 75% completion has 10 GB left. The result assumes the application can resume cleanly. Some services verify existing data or restart individual chunks, which can add time.

Required speed for a deadline

The required-speed mode reverses the time formula:

Required effective speed = file size in bits ÷ available seconds.

Because overhead and shared bandwidth reduce usable throughput, the connection itself must provide:

Required connection speed = required effective speed ÷ efficiency ÷ bandwidth share.

How much data can transfer in a fixed time

The data-capacity mode applies:

Transferred data = effective speed × duration.

At an effective 100 Mbps, one hour carries 360,000 megabits, or 45 decimal gigabytes. At 85 Mbps, the same hour carries about 38.25 GB. This calculation helps plan cloud backups, data migrations and limited connection windows.

File-size conversion and compression

The size mode multiplies one file by a quantity and optionally estimates a percentage reduction:

Combined size = one-file size × quantity.

Final size = combined size × (1 − reduction percentage ÷ 100).

Space saved = combined size − final size.

A compression percentage remains an assumption. Already compressed formats such as many videos, images and archives may shrink very little. Plain text, raw data and some documents often compress more effectively.

Server, storage and device bottlenecks

The internet plan does not always set the final limit. Servers, storage, antivirus software, router capacity and Wi-Fi conditions can all restrict application throughput.

When a real transfer stays far below the estimate, compare wired and wireless results, test another server, pause competing traffic, inspect storage activity and review VPN or security software.

Practical examples

Downloading a 50 GB game

At 300 Mbps, 85% efficiency and full bandwidth availability, the effective rate equals 255 Mbps. A decimal 50 GB download requires about 26 minutes and 9 seconds. With only 50% of the connection available, the estimate doubles to roughly 52 minutes and 17 seconds.

Uploading a 200 GiB backup

A 200 GiB backup contains about 1.718 trillion bits. At an effective upload rate of 40 Mbps, the transfer takes about 11 hours and 56 minutes. Upload speed matters here; many consumer connections provide much lower upload than download capacity.

Finishing a partial file

A 12 GB file at 65% completion has 4.2 GB remaining. At an effective 70 Mbps, the remaining transfer takes about eight minutes. Verification or decompression may continue after the network transfer ends.

Common mistakes

• treating Mbps as MB/s;
• mixing GB and GiB without noticing the difference;
• using the advertised speed as guaranteed application throughput;
• ignoring a much slower upload rate;
• forgetting other devices and active transfers;
• calculating from the full file after most of it has already downloaded;
• assuming compression always reduces every format by the same percentage;
• treating the predicted completion time as a guarantee.

How to improve the estimate

Use the actual transfer direction, match the file source’s unit system, enter a realistic bandwidth share and start with 80% to 90% efficiency on a stable connection. Compare one observed transfer with the prediction and adjust the efficiency.

For important migrations, add a safety margin and test a representative sample. A test reveals server throttling, storage limitations and authentication delays that a formula cannot discover alone.

Frequently asked questions

Official technical references

• NIST: binary prefixes and the difference between SI and binary multiples
• IEC: prefixes for binary multiples
• NIST Guide to SI prefixes
• RFC 9293: Transmission Control Protocol
• RFC 9000: QUIC transport
• RFC 9002: QUIC loss detection and congestion control

Sources reviewed: 20 June 2026.