File Transfer Time Calculator

Transfer direction:

Download, upload, or copy/sync; the speed field should match that direction.

File size:

Enter the source size, then choose MB/GB/TB and the matching size standard.

Size standard:

Choose IEC for KiB/MiB/GiB sources; SI for KB/MB/GB portal values.

Bandwidth:

Use the sustained value, e.g. 100 Mbps from a plan or 90 MB/s from a copy log.

Transfer profile:

Pick Custom to keep manual values, or load LAN, WAN, backup, or VPN baselines.

Target window:

Enter 0 to disable, or set minutes/hours/days for a maintenance budget.

Protocol preset:

Choose Custom to keep manual overhead and handshake values.

{{ err }}

Start time:

Optional local date/time for finish planning; leave blank for Starts now.

Overhead: {{ overhead_percent }}%

Use 0-50%; HTTPS often 3-5%, SFTP 5-10%, SMB/NFS 5-12%.

Compression: {{ compression_percent }}%

Use 0-90%; text or logs may shrink, photos and videos usually do not.

Latency (RTT):

Enter average round-trip ms; use 0 to skip WAN/TCP ceiling effects.

TCP window:

Use 0 for no receive-window cap, or enter MB per TCP flow.

Connections:

Use 1 by default; try 2-8 only for high-RTT paths that cannot fill the link.

flows

Bandwidth share: {{ bandwidth_share_percent }}%

Use 1-100%; 100 means the transfer can use the whole entered rate.

Packet loss:

Use 0 to skip loss modeling; WAN samples are often 0.01-0.1%.

MSS:

Typical values: 1460 for Ethernet IPv4, about 1440 for IPv6/VPN paths.

bytes

Mathis C:

Accepted positive value; common sensitivity checks use about 1.1-1.3.

Handshake RTTs:

Use 0 for reused sessions; HTTPS often 2, SFTP often 1.

RTT

Aspect	Value	Details	Copy
{{ row.label }}	{{ row.value }}	{{ row.details }}

Metric	Value	Copy
Total bytes	{{ format(total_bytes) }}
Effective bytes	{{ format(effective_bytes) }}
Raw rate (B/s)	{{ format(raw_bps) }}
After share (B/s)	{{ format(available_raw_bps) }}
Post-overhead (B/s)	{{ format(post_overhead_bps) }}
BDP cap (B/s)	{{ bdp_limit_bps ? format(bdp_limit_bps) : 'N/A' }}
Loss cap (B/s)	{{ loss_limit_bps ? format(loss_limit_bps) : 'N/A' }}
Effective (B/s)	{{ format(eff_bps) }}
Handshake time (s)	{{ format(handshake_time_seconds) }}
Time (s)	{{ format(transfer_time_seconds) }}
Finish (local)	{{ finish_time_local }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A transfer schedule is rarely decided by the file size and the advertised link speed alone. Backups, cloud uploads, media handoffs, virtual machine copies, and site-to-site sync jobs all start with the same basic question: how many bytes must move, and what sustained rate can the path really deliver until the last byte arrives?

The first estimate is simple. Divide the payload by the throughput and the result is elapsed time. The hard part is choosing the right payload and the right throughput. Storage tools usually describe size in bytes, while networks usually advertise speed in bits per second. A 100 Mbps uplink is about 12.5 MB/s before any overhead, sharing, retransmission, or application delay is counted.

Payload: The bytes that still need to cross the path after size-unit conversion and any expected compression.
Raw bandwidth: The entered port, plan, copy-log, or measured rate before link share and protocol overhead are applied.
Throughput ceiling: A limit that can cap the transfer rate, such as protocol overhead, TCP window size, round-trip time, or packet loss.
Time window: The maintenance period, backup window, delivery promise, or upload deadline the transfer must fit inside.

Diagram of payload bytes passing through bandwidth share, overhead, RTT window, and packet loss ceilings before becoming elapsed transfer time.

Long-distance paths add another planning problem. TCP needs enough data in flight to fill a path while acknowledgements travel back. A small receive window can keep a fast link underused when round-trip time is high. Packet loss can do the same by forcing the sender to slow down, and that effect grows more visible on high-latency paths.

A transfer-time estimate is strongest when the size, sustained rate, latency, and loss come from the same path and the same kind of file. It becomes a rough what-if model when the bandwidth is only a service-plan number, compression is guessed, or the real transfer will compete with other traffic, disk limits, encryption, virus scanning, or application throttling.

How to Use This Tool:

Enter the measured values first, then add path limits and deadline checks only when they are relevant to the plan.

Set Transfer direction to download, upload, or copy/sync so the summary and finish wording match the job. Use a bandwidth value measured in that same direction.
Enter File size, choose the matching size unit, and set Size standard. Use SI for decimal storage labels such as GB and TB, or IEC when the source uses binary size accounting such as GiB and TiB.
Enter Bandwidth in a bit-rate or byte-rate unit. If the result is about eight times too fast or too slow, recheck whether the source number was Mbps, MB/s, Gbps, or GB/s.
Choose a Transfer profile when a common baseline helps. The profile can fill assumptions for LAN copies, home uploads, cross-region sync, shared backup windows, or VPN handoffs. Select Custom when you want to keep manual values.
Use Target window when the copy must fit a maintenance period or backup slot. The Transfer Snapshot tab reports whether the modeled transfer fits and how much time is spare or missing.
Open Advanced for start time, protocol overhead, compression, bandwidth share, RTT, TCP window, connection count, packet loss, maximum segment size, Mathis C, and handshake RTTs. Leave RTT, window, and loss at zero when you do not want those ceilings to participate.
Fix validation messages before reading the results. File size and bandwidth must be above zero, packet loss must stay within the accepted range, target window cannot be negative, and a start time must be a valid local date and time when entered.

Interpreting Results:

Read Total time with Usable throughput and Active limiter. The elapsed time is more useful when the limiting factor points to something concrete, such as a shared link, protocol overhead, a receive-window ceiling, or a loss ceiling.

Transfer Snapshot is the planning view, with elapsed time, finish time, window fit, startup drag, active limiter, and improvement suggestions when a change would save time.
Transfer Metrics is the audit view, including total bytes, payload after compression, raw bandwidth, available bandwidth, post-overhead rate, BDP cap, loss cap, effective rate, handshake delay, and finish time.
Transfer Ceiling Stack compares the active rate ceilings. The smallest non-zero rate is the one used for the final duration.
Transfer Completion Curve plots cumulative bytes over elapsed seconds and adds a target-window marker when a deadline is set.

A result that fits a window is still only as trustworthy as the assumptions. Run a sample transfer when the margin is tight, when loss is non-zero, or when compression is the reason the transfer appears to fit.

Technical Details:

Transfer duration is bytes divided by sustained bytes per second, with startup round trips added before payload movement. The model converts the entered file size to bytes, applies compression as a payload reduction, converts entered bandwidth to bytes per second, then applies bandwidth share, protocol overhead, and any active TCP ceilings.

The RTT/window ceiling is a bandwidth-delay product check. With a positive round-trip time and receive window, the sender can only keep so many bytes in flight per connection. The loss ceiling follows a simplified Mathis-style TCP estimate, where throughput falls as RTT rises and as the square root of packet loss rises.

Formula Core:

The final rate is the smallest active ceiling. The post-overhead rate is always considered; RTT/window and loss ceilings are considered only when the needed inputs are positive.

\begin{matrix} B_{payload} & = & B_{total} \times (1 - c) \\ R_{post} & = & R_{raw} \times s \times (1 - o) \\ R_{window} & = & \frac{W \times 1000000 \times n}{{RTT}_{s}} \\ R_{loss} & = & \frac{MSS \times C}{{RTT}_{s} \times \sqrt{p}} \\ R_{eff} & = & min (R_{post}, R_{window}, R_{loss}) \\ T_{total} & = & (h \times {RTT}_{s}) + \frac{B_{payload}}{R_{eff}} \end{matrix}

Symbols and units used in the file transfer time formula
Symbol	Meaning	Unit or source
B payload	Payload bytes after compression	Bytes
R raw	Entered bandwidth converted to bytes per second	Bit-rate units are divided by 8; byte-rate units are decimal
s	Bandwidth share fraction	1% to 100%
o	Protocol overhead fraction	Percent divided by 100
W	TCP receive window per flow	Decimal MB in the window formula
p	Packet loss probability	Packet loss percent divided by 100
h	Startup round trips before payload transfer	Handshake RTT count

For a 12 GB SI payload at 125 MB/s with 10% overhead and no compression, the post-overhead rate is 125,000,000 B/s times 0.90, or 112,500,000 B/s. With no RTT/window or loss ceiling active, total duration is 12,000,000,000 divided by 112,500,000, which is about 106.7 seconds.

Transfer time validation limits and boundary rules
Input	Accepted range or rule	Effect on the model
File size and bandwidth	Both must be greater than 0	The duration requires a positive payload and a positive rate
Size standard	SI uses powers of 1000 for KB, MB, GB, and TB; IEC uses powers of 1024	Binary and decimal prefixes can change large-file byte counts materially
Overhead and compression	Overhead 0% to 95%; compression 0% to 90%	Overhead lowers the rate; compression lowers the modeled payload
RTT, TCP window, and connections	RTT and window cannot be negative; connections are floored to a positive whole number	Positive RTT and window values enable the BDP cap
Packet loss, MSS, and Mathis C	Loss must stay from 0% to 20%; MSS and Mathis C must stay positive within the accepted controls	Positive loss and RTT enable the simplified loss cap
Handshake RTTs and target window	Handshake count and target window must be nonnegative	Handshake RTTs add startup delay; target window compares the final total time with the deadline

TCP throughput standards and guidance treat bottleneck bandwidth, round-trip time, receive-window sizing, MTU, and loss as central measurement variables. The file-size side follows the SI and binary-prefix distinction, which is why a decimal GB value and a binary GiB value are not interchangeable in a tight schedule.

Accuracy Notes:

The estimate is a planning model. It does not inspect the file, test the live network, measure disk speed, or know whether another process will take part of the link during the transfer.

Compression depends on file contents. Text, logs, and database dumps may shrink; photos, videos, encrypted files, and archives usually do not shrink much.
Protocol presets are starting assumptions. A VPN, filesystem, application, proxy, or transfer client can add overhead beyond the preset.
The packet-loss ceiling is a simplified TCP estimate. Modern congestion control, burst loss, retransmission timeouts, application throttles, and storage limits can produce different real throughput.
The page does not ask for a file. It calculates from the entered numbers, so privacy risk is mainly the choice to share or bookmark a URL that contains settings.

Worked Examples:

Local NAS copy with SMB overhead

A 12 GB SI copy at 125 MB/s with 10% overhead, 1 ms RTT, a 32 MB TCP window, one connection, and no packet loss should show usable throughput near 112.5 MB/s. Total time should be about 1 m 46 s, and the active limiter should be the link share plus protocol overhead.

WAN sync capped by receive window

An 80 GB SI transfer over 1 Gbps with 3% overhead, 120 ms RTT, one connection, a 4 MB TCP window, and no loss is limited by the receive-window calculation. BDP cap and Effective throughput should be about 33.3 MB/s, so total time lands near 40 minutes.

Upload that misses the backup window

A 100 GB SI upload on a 20 Mbps link with 75% bandwidth share, 3% overhead, 25 ms RTT, 8 MB window, 0.05% packet loss, and an 8-hour Target window misses by roughly 7 h 16 m. Check the unit first because entering 20 MB/s instead of 20 Mbps changes the schedule dramatically.

FAQ:

Why is the estimate about eight times different from my expectation?

Bits and bytes are usually mixed. Mbps and Gbps are bit rates, while MB/s and GB/s are byte rates. Bit-rate units are divided by 8 before transfer time is calculated.

Why can the TCP window limit a fast link?

A sender needs enough unacknowledged data in flight to fill a path while acknowledgements return. When RTT is positive and the receive window is too small, BDP cap can fall below the post-overhead link rate.

Why does a small packet-loss percentage matter?

The simplified loss ceiling falls as packet loss increases and as RTT increases. On long paths, a small non-zero loss value can push Loss cap below the bandwidth-based rate.

Should compression be entered for every transfer?

No. Enter compression only when the real workflow is expected to shrink the payload. Already compressed or encrypted files usually need a low or zero compression assumption.

Does the calculator upload or read my file?

No. It does not ask for a file and estimates from the numbers entered. Use a measured sample transfer when a deadline is tight or the file mix may compress differently than expected.

Glossary:

Bandwidth-delay product: The amount of data needed in flight to keep a path full at a given bandwidth and round-trip time.
Effective throughput: The sustained byte rate left after share, overhead, receive-window, and loss limits are considered.
Handshake RTTs: Startup round trips counted before payload bytes begin moving.
Maximum segment size: The TCP payload bytes per segment used by the simplified packet-loss estimate.
Packet loss: The fraction of packets assumed to be lost on the path, entered as a percentage.
Target window: The available time budget used to decide whether the modeled transfer fits or misses a deadline.

References:

RFC 6349: Framework for TCP Throughput Testing, IETF, August 2011.
RFC 7323: TCP Extensions for High Performance, IETF, September 2014.
RFC 3819: Advice for Internet Subnetwork Designers, IETF, July 2004.
The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm, ACM SIGCOMM Computer Communication Review, July 1997.
Definitions of the SI units: The binary prefixes, NIST.
The International System of Units (SI), 2019 Edition, NIST, August 1, 2019.
How to transfer a file over TCP with Netcat, Simplified Guide.