Parallel Upload Techniques: Maximize Transfer Bandwidth
Learn how parallel uploads dramatically speed up file transfers. Understand chunked uploads, multi-connection transfers, and how modern services use them.
Parallel uploads split a file into chunks (typically 5 MB to 100 MB each) and push them over multiple concurrent TCP connections, bypassing the throughput ceiling a single stream hits on high-latency links. Amazon S3 multipart upload, Google Cloud Storage resumable uploads, and tus.io all implement this. On a 1 Gbps line with 80 ms latency to the destination server, a single HTTP PUT typically saturates at 150 Mbps, while 8 parallel streams push past 900 Mbps. The gain is real and predictable once you understand why.
Why one stream isn't enough
TCP's congestion control uses a sliding window to decide how much unacknowledged data to keep in flight. On a fat, high-latency pipe, the default window size (around 16 MB on Linux 5.x, less on older kernels) fills before ACKs return, and the sender sits idle waiting. This is the "bandwidth-delay product" problem, and it's the reason a single FTP transfer to a server in Singapore from Paris caps out around 30 Mbps even on a gigabit line.
Running multiple parallel connections sidesteps the issue because each connection gets its own window. Eight streams of 30 Mbps add up to 240 Mbps, and that's before you account for CDN edge selection, which often routes different connections through different ingress points.
Chunking: what size, how many
The sweet spot depends on latency and packet loss. For same-continent transfers under 50 ms RTT, 10 MB chunks with 4 parallel workers saturates most consumer lines. For transcontinental or lossy mobile links (over 100 ms RTT, over 0.5% packet loss), drop to 5 MB chunks with 8 to 16 workers.
S3's multipart API requires a minimum 5 MB per part (except the last), a maximum of 5 GB per part, and up to 10,000 parts per upload. That puts the theoretical ceiling at around 48.8 TB per object. Google Cloud Storage allows 32 parts per composite and supports resumable session URIs that persist for up to one week. Azure Blob block blobs accept up to 50,000 blocks at 4000 MiB each.
For browser-based transfers, chunks above 100 MB start stressing RAM on tabs that are already loaded, so most web UIs stay between 5 MB and 20 MB.
How modern transfer services actually do it
WeTransfer's web uploader splits files into 6 MB chunks and runs 3 to 5 parallel XHR requests. Smash shards more aggressively, with 4 MB chunks across up to 8 workers. SwissTransfer uses 50 MB chunks with 4 parallel streams, which favours throughput on Swiss fibre lines but performs worse on unstable connections because a single failed chunk means retransmitting 50 MB. Dropbox Transfer leans on its chunked upload API with 8 MB chunks.
The differences show up in real-world tests: a 5 GB file on a 500 Mbps upload to WeTransfer finishes in roughly 95 seconds; SwissTransfer at similar throughput runs about 105 seconds because of occasional chunk retry overhead.
Resumable uploads: the quiet superpower
Chunked uploads unlock resume. If your Wi-Fi drops at chunk 47 of 120, you don't restart from zero, you resume from chunk 48. The tus.io protocol (an open standard now on version 2.0) formalises this with HEAD requests to query upload offset and PATCH requests to append, using Upload-Offset and Upload-Length headers.
Google Drive's resumable upload API uses session URIs that persist for 7 days. You can crash a laptop, reboot, reopen the tab, and pick up exactly where you left off. This is the difference between a usable 10 GB transfer and a coin-flip.
Client-side encryption changes the math
End-to-end encrypted transfer services have to encrypt each chunk on the client before sending. AES-256-GCM at 500 MB/s on a modern laptop CPU isn't the bottleneck, but the order matters: encrypt chunk, upload chunk, encrypt next chunk. Pipelining with a worker pool matters here. Naive implementations serialise encryption and upload, cutting effective throughput in half. Proper implementations keep 2 to 4 encryption workers feeding 4 to 8 upload workers through a bounded queue.
This is why HexaTransfer runs AES-256-GCM encryption in Web Workers alongside a parallel XHR pool, so the 10 GB ceiling is actually reachable in browser without stalling on crypto.
Backpressure and server-side limits
More parallelism isn't always faster. If the receiving service rate-limits per IP (common with CloudFront at 25,000 requests per second per distribution), pushing 32 concurrent chunks can trigger 503 Slow Down responses. HTTP/2 helps because it multiplexes over a single TCP connection, but many CDNs still terminate HTTP/2 at the edge and fan out HTTP/1.1 to origin, so the effective parallelism depends on edge configuration.
Test before over-parallelising. 8 workers is almost always safe; 16 is the upper end of what cloud object stores will accept cleanly; 32 starts producing retries that cost more than they save.
Browser limits you should know
Chrome and Firefox cap concurrent connections per origin at 6 over HTTP/1.1 and effectively unlimited over HTTP/2. If the transfer service is still on HTTP/1.1 (rare, but some legacy FTP-over-HTTP gateways), your parallelism ceiling is 6 regardless of how many workers you spin up. Check with DevTools: the "Waterfall" column in the Network panel shows queued requests stacking up.
Safari on iOS 17 and later handles 6 parallel XHR cleanly but starts evicting background tabs at around 1.5 GB of RAM pressure, which matters for chunked upload buffers.
When parallel uploads don't help
On asymmetric residential connections (typical: 1 Gbps down, 40 Mbps up), your upload is the bottleneck, not the server's ingest. Pushing 8 parallel streams at 5 MB each through a 40 Mbps pipe doesn't go faster than 1 stream at 40 Mbps. Parallelism helps when the single-stream ceiling is below the pipe's capacity, not when you're already saturating the link.
Same story on cellular: if you've got one bar of LTE, extra workers mostly produce retransmits.
What to look for in a service
If you're picking a transfer tool for frequent large files, check three things: does it support resumable chunked uploads, how many parallel workers does the web UI run, and does it use HTTP/2 or HTTP/3 to the edge. Services that hit all three will move a 10 GB file in minutes on a decent connection.
Try it at hexatransfer.com — free, no account, 10 GB max.
Send large files securely with end-to-end encryption
Transfer files up to 10 GB for free with end-to-end encryption. No account required. Your files are encrypted in your browser before upload — no one else can read them.
Send a file