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

Long transfers are usually planned from two numbers: how much data needs to move and how fast the path can carry it. That simple view is useful for a first estimate, but it misses the reason backups, cloud uploads, site-to-site sync jobs, and large media deliveries often finish later than the headline link speed suggests.

The file size is only the starting payload. The usable rate can be reduced by a shared link, protocol overhead, a high round-trip time, a small TCP receive window, or packet loss that forces congestion control to slow down. A path that can move small files comfortably may still be a poor fit for a multi-terabyte copy if it cannot keep enough data in flight.

Payload bytes: The amount of data that remains after size conversion and any expected compression.
Advertised bandwidth: The speed printed on a port, plan, or copy log before share and overhead are considered.
Effective throughput: The sustained rate left after all active transfer ceilings are applied.
Target window: The maintenance, delivery, or backup budget the transfer must fit inside.

Diagram of payload bytes passing through bandwidth, overhead, latency, TCP window, and packet loss limits before becoming elapsed transfer time.

Unit wording is another common source of bad schedules. Network speeds are usually advertised in bits per second, while file sizes and copy logs often use bytes. A 100 Mbps connection does not move 100 MB every second; before any overhead, it is about 12.5 MB/s. Storage prefixes can also differ. SI prefixes use powers of 1000, while binary prefixes such as KiB, MiB, and GiB use powers of 1024.

A transfer estimate should be treated as a planning model, not a proof that the next real job will finish at that exact time. It is strongest when the entered bandwidth, round-trip time, loss, and overhead come from a recent sample on the same path. It is weakest when it assumes a perfect link, ignores competing traffic, or treats a compressible database dump and a compressed video archive as if they shrink the same way.

How to Use This Tool:

Start with the values you trust most, then add the advanced path limits only when they are known or useful for a what-if plan.

Choose Transfer direction so the summary reads as a download, upload, or copy/sync plan. Enter the speed that applies to that same direction.
Set File size, Size standard, and Bandwidth. Recheck the unit when the estimate is roughly eight times too fast or too slow because that usually means bits and bytes were mixed.
Use Transfer profile for a starting scenario such as a clean LAN copy, home upload, cross-region sync, shared backup window, or branch VPN handoff. Switch back to Custom when you want to keep your own assumptions.
Set Target window when a transfer must fit a maintenance period or delivery deadline. The Transfer Snapshot tab will report whether the current model fits or misses that budget.
Open Advanced for start time, overhead, compression, bandwidth share, latency, TCP window, connection count, packet loss, maximum segment size, Mathis C, and handshake RTTs. Keep unknown loss or RTT values at zero when you do not want those ceilings included.
Use Protocol preset to fill common overhead and startup assumptions for HTTPS, SFTP, SMB, or NFS, then adjust the percentages if your measured workflow differs.
If a red validation message appears, fix the named field before trusting the estimate. Common causes are a zero file size, zero bandwidth, negative target window, out-of-range packet loss, or an invalid local start time.

Interpreting Results:

Use Usable throughput and Active limiter together. A short transfer time is less convincing when the active limiter depends on a guessed packet-loss value or an optimistic bandwidth share. A longer estimate is more actionable when it points to a concrete ceiling such as RTT/window, protocol overhead, or link share.

Transfer Snapshot gives the planning answer: usable throughput, finish estimate or window status, startup drag, active limiter, and the best next tweak when one improves the estimate.
Transfer Metrics is the audit view: total bytes, effective bytes, raw rate, after-share rate, post-overhead rate, BDP cap, loss cap, effective rate, handshake time, total seconds, and local finish time.
Transfer Ceiling Stack shows which throughput ceiling is smallest. The smallest non-zero ceiling is the rate used for the final duration.
Transfer Completion Curve shows cumulative bytes over elapsed seconds, including startup delay and the target-window marker when a window is set.

Do not treat a fit result as a guarantee. Verify tight schedules with a real sample transfer or measured throughput on the same path, especially when the target window has little spare time, packet loss is non-zero, or the transfer depends on compression that may not apply to the actual files.

Technical Details:

Transfer time is governed by bytes divided by a sustained byte rate, plus any startup delay. The model first converts the entered size to bytes, reduces that payload by the compression percentage, converts the entered bandwidth to bytes per second, then applies the active throughput ceilings.

The receive-window ceiling is a bandwidth-delay product check expressed as a rate: a sender cannot sustain more data per second than the configured receive window allows across one round trip. The packet-loss ceiling follows a simplified Mathis-style TCP throughput estimate where throughput falls as round-trip time rises and as the square root of packet loss rises.

Formula Core:

The final duration uses the smallest active throughput ceiling. RTT/window and loss ceilings are omitted when their required inputs are zero.

\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 by the transfer time model
Symbol	Meaning	Unit or source
B payload	Payload bytes after compression	Bytes
R raw	Entered bandwidth converted to bytes per second	Bit units are divided by 8; byte-rate units are decimal
s	Bandwidth share	1% to 100%
o	Protocol overhead fraction	Percent divided by 100
W	TCP receive window per flow	Decimal MB in the receive-window formula
p	Packet loss probability	Packet loss percent divided by 100
h	Startup handshakes	Count of RTTs added before payload transfer

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 active RTT/window or loss ceiling, the total duration is 12,000,000,000 divided by 112,500,000, which is about 106.7 seconds.

Validation limits for transfer time inputs
Input	Accepted range or condition	Why it matters
File size	Greater than 0	No positive payload means no meaningful transfer duration
Bandwidth	Greater than 0	The final division needs a positive rate
Overhead and compression	Overhead 0% to 95%; compression 0% to 90%	Extreme percentages can erase the usable rate or payload
Bandwidth share	1% to 100%	The modeled transfer must reserve some part of the entered rate
RTT, TCP window, and connections	RTT and window cannot be negative; connections 1 to 32	These values define the receive-window ceiling when RTT and window are both positive
Packet loss, MSS, and Mathis C	Loss 0% to 20%; MSS 200 to 9000 bytes; Mathis C above 0 and no more than 10	These values define the simplified loss ceiling when RTT and loss are both positive
Handshake RTTs and target window	Handshake RTTs 0 to 20; target window cannot be negative	Startup delay and deadline checks depend on nonnegative time values

RFC 6349 treats bottleneck bandwidth, RTT, receive-window sizing, MTU, and loss as central TCP throughput variables. RFC 7323 explains the window scaling needed for large receive windows, while RFC 3819 notes that high delay and packet loss make it harder for TCP to use a high-speed path fully. The size-standard choice follows the SI and binary-prefix distinction used by NIST and IEC-style binary prefixes.

Accuracy Notes:

Use the estimate as a planning aid and sensitivity check. It models the values entered; it does not inspect the file, test the live network, or measure storage speed.

Compression is an assumption. Text, logs, and database dumps may shrink; media files and archives usually do not.
Protocol presets are starting points. A real transfer tool, VPN, filesystem, or application can add overhead not represented by a generic preset.
The Mathis loss ceiling is a simplified TCP model, strongest for light to moderate random loss and weaker when timeouts, modern congestion-control behavior, or application throttling dominate.
Target-window results are only as good as the entered rate, share, RTT, loss, and start time.

Worked Examples:

NAS copy with protocol overhead

A 12 GB SI copy at 125 MB/s with SMB-style 10% overhead, 1 ms RTT, a 32 MB TCP window, and no packet loss should show Usable throughput near 112.5 MB/s. Active limiter should read link share plus protocol overhead, and Total time in Transfer Metrics should be about 1 m 46 s.

WAN sync limited by receive window

An 80 GB SI copy 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, and Total time should land near 40 minutes. A 45-minute Target window should fit with several minutes spare.

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 TCP window, 0.05% packet loss, and an 8-hour Target window misses by roughly 7 h 16 m. Needed effective throughput should be about 3.47 MB/s, so first check whether the intended bandwidth was 20 MB/s rather than 20 Mbps before changing network assumptions.

FAQ:

Why is my estimate about eight times off?

Bits and bytes are the usual cause. Mbps and Gbps are bit rates, while MB/s and GB/s are byte rates. The calculator divides bit-rate units by 8 before calculating transfer time.

Why can the TCP window be the active limiter?

A high-latency path needs enough unacknowledged data in flight to fill the link. When RTT is positive and the TCP window is too small, the BDP cap can become smaller than the post-overhead rate.

Why does a tiny packet-loss value matter?

The loss ceiling falls with the square root of packet loss and also falls as RTT rises. On long paths, a small non-zero packet-loss percentage can push Loss cap below the bandwidth-based rate.

What should I fix when results disappear?

Read the red validation message first. The calculator requires file size and bandwidth above zero, nonnegative RTT and target window values, packet loss from 0% to 20%, MSS from 200 to 9000 bytes, and a valid local start time when one is entered.

Does the calculator upload my file?

No. It does not ask for a file. The estimate is calculated from the numbers entered, so use a measured sample transfer when the schedule is tight or the file type may compress differently than expected.

Glossary:

Bandwidth-delay product: The amount of data needed in flight to fill a path at a given bandwidth and round-trip time.
Effective throughput: The sustained byte rate after bandwidth share, overhead, receive-window limits, and loss limits are considered.
Handshake RTTs: The 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.