File Transfer Time Calculator

Usable rate{{ resultsReady ? formatRate(computation.values.effective_rate_bps) : '—' }} Ceiling{{ resultsReady ? limitingFactorLabel : '—' }} Window{{ windowStatus }}

Transfer direction:

Use the bottleneck rate for the selected direction.

File size:

Choose the unit printed by the source system.

Size standard:

Explicit KiB, MiB, GiB, and TiB always use powers of 1024.

Sustained bandwidth:

Bits and bytes are converted explicitly; 100 Mbps is 12.5 MB/s before other limits.

Transfer profile:

Protocol preset:

Custom keeps your current overhead and handshake values.

Target window:

Use 0 to disable the deadline comparison.

Protocol overhead:

Use 0 when overhead is unknown or already reflected in the sustained rate.

Payload compression:

Use 0 for archives, photos, video, or other already-compressed data.

Bandwidth share:

100% gives this transfer the full entered sustained rate.

Round-trip time:

Use the end-to-end RTT; 0 disables RTT-dependent ceilings.

TCP window per flow:

0 disables the receive-window ceiling.

Parallel connections:

flows

Use 1 unless the transfer application opens parallel data flows.

Packet loss:

0 disables the approximate loss ceiling.

TCP MSS:

bytes

1460 bytes is a common Ethernet-path planning value.

Mathis constant:

Keep 1.22 unless another documented model supplies a different constant.

Startup handshakes:

RTT

0 adds no startup delay.

Start time:

Leave blank to report duration without a calendar finish time.

{{ row.label }}{{ row.display }}

Calculation method:

The result is an estimate; real applications may add storage, server, congestion-control, and retry effects.

{{ row.label }}: {{ row.display }}{{ row.detail }}

The chart renderer is unavailable. The same values remain in the transfer ledger.

Signal	Value	Meaning	Copy
{{ row.label }}	{{ row.display }}	{{ row.detail }}

A file can cross a fast local network in seconds and take hours over an internet upload even when its size never changes. The deciding quantity is sustained end-to-end throughput: the rate that remains available after the slowest link, competing traffic, protocol work, latency, and loss have taken their share.

File size and network speed are often printed in different units. Storage is measured in bytes, while network links are commonly advertised in bits per second. Eight bits make one byte, so a 100 Mbps connection has a raw ceiling of 12.5 MB/s before any other reduction. Decimal and binary size labels also matter. One GB is 1,000,000,000 bytes under SI, while one GiB is 1,073,741,824 bytes.

Sustained bandwidth: The rate the path can hold during the transfer, not a brief speed-test peak or the provider's advertised maximum.
Round-trip time (RTT): The time for data to reach the far end and an acknowledgment to return. A long RTT requires more data in flight to fill a fast path.
TCP window: The amount of unacknowledged data one flow may have in transit. A small window can cap throughput on a high-latency path.
Packet loss: Missing packets trigger recovery and reduce the rate that loss-sensitive congestion control can sustain.

Compression changes the number of bytes sent only when the source data is compressible. Text, database dumps, and some backups may shrink substantially. Archives, photos, audio, and video are usually already compressed, so applying another optimistic reduction can produce an unrealistically short estimate.

A transfer-time estimate is most useful for backup windows, migrations, remote uploads, and capacity planning. It is not a guarantee. Disk speed, encryption, application buffering, server limits, changing congestion, retransmissions, and protocol behavior can all make a real transfer slower. Measure a representative sustained rate whenever the deadline matters.

How to Use This Tool:

Start with the bottleneck rate for the selected direction, then add only the limits you can support with measurements or documented assumptions.

Choose Transfer direction, enter the File size, and match its printed unit and Size standard. Explicit KiB, MiB, GiB, and TiB always use powers of 1024.
Enter Sustained bandwidth in bits or bytes per second. Set a Target window when the transfer must finish before a backup, migration, or maintenance deadline; zero disables that comparison.
Select a Transfer profile or enter your own assumptions. Protocol overhead, payload compression, and bandwidth share change the basic byte-rate. RTT, TCP window, parallel connections, packet loss, and MSS enable additional TCP ceilings.
Review Transfer plan for duration and deadline margin. Check Throughput ceilings when the usable rate is lower than expected, then use the Transfer ledger to see which assumption caused the reduction.

Interpreting Results:

Estimated transfer time combines payload time with any entered startup handshakes. Usable rate is the lowest active ceiling, so increasing the entered link speed will not shorten the estimate when the TCP window or loss model is already lower.

Post-overhead means bandwidth share and protocol overhead are the active limit.
TCP window means the entered window, RTT, and flow count cannot keep enough bytes in flight to use the available rate.
Packet loss is an approximate congestion-control ceiling, not a prediction for every TCP implementation.
A deadline marked Fits means the modeled duration is no greater than the target window. It does not reserve bandwidth or account for later congestion.

Technical Details:

The calculation converts the file to bytes and the entered bandwidth to bytes per second. Compression reduces payload bytes. Bandwidth share and protocol overhead reduce the link rate. When their required inputs are above zero, receive-window and packet-loss estimates become competing ceilings.

Formula Core

The effective rate is the minimum of the active ceilings, and total time is payload time plus startup delay.

\begin{aligned} B_{effective} & = B \times (1 - c) \\ R_{link} & = R \times s \times (1 - o) \\ R_{window} & = \frac{W \times n}{RTT} \\ R_{loss} & = \frac{MSS \times C}{RTT \times \sqrt{p}} \\ R_{effective} & = \min (R_{link}, R_{window}, R_{loss}) \\ T & = \frac{B_{effective}}{R_{effective}} + (h \times RTT) \end{aligned}

B is total bytes; c is compression as a decimal; R is the entered raw byte-rate; s is bandwidth share; o is protocol overhead; W is the TCP window per flow in decimal bytes; n is the number of parallel connections; p is packet loss as a decimal; MSS is the maximum segment size in bytes; C is the Mathis constant; and h is the number of startup RTTs.

The window ceiling is used only when both RTT and TCP window are above zero. The loss ceiling is used only when RTT and packet loss are above zero. Otherwise the post-overhead rate remains available without that particular constraint. The default Mathis constant is 1.22, and the loss equation is a planning approximation for congestion avoidance rather than a complete simulation of slow start, retransmission timeouts, modern congestion-control variants, or application behavior.

Units and deadline rule

Transfer unit and deadline rules
Item	Rule
KB, MB, GB, TB under IEC	Powers of 1024, matching the selected IEC size standard.
KB, MB, GB, TB under SI	Powers of 1000.
KiB, MiB, GiB, TiB	Always powers of 1024.
Kbps, Mbps, Gbps	Decimal bits per second, divided by 8 to obtain bytes per second.
Deadline	Fits when target seconds minus transfer seconds is greater than or equal to zero; zero disables the test.

Protocol preset lookup

Protocol preset overhead and startup assumptions
Preset	Overhead	Startup RTTs
HTTPS	3%	2
SFTP	5%	1
SMB	10%	0
NFS	8%	0

Custom leaves the entered overhead and startup values unchanged. No intermediate value is rounded before later calculations; durations and rates are formatted for display only after the full-precision result is available.

Accuracy Notes:

The estimate is strongest when file size, sustained bandwidth, RTT, loss, and TCP-window values come from the same end-to-end path.

Protocol presets are planning assumptions. A real application may add encryption, metadata, checksums, retries, server throttling, or storage delays that the preset does not capture.
Parallel connections multiply only the receive-window ceiling. They do not multiply the entered bandwidth or the loss ceiling.
The compression percentage is an input, not a file inspection. Leave it at zero for data that is already compressed unless a measured transfer proves otherwise.
Use a timed representative transfer to validate a critical migration or backup window, then replace assumptions with the measured sustained rate.

Worked Examples:

Binary file size over a decimal link

A 10 GiB file contains 10,737,418,240 bytes. At 100 Mbps, the raw rate is 12,500,000 bytes per second. With full bandwidth share, no overhead, no compression, and no RTT-dependent ceiling, the payload takes about 859 seconds, or 14 minutes 19 seconds. Treating 10 GiB as 10 GB would understate the byte count and shorten the estimate.

References:

RFC 6349: Framework for TCP Throughput Testing, RFC Editor, August 2011.
Definitions of the SI units: The binary prefixes, National Institute of Standards and Technology.
How to transfer a file over TCP with Netcat, Simplified Guide.