Resume Interrupted Transfers: Never Restart from Zero

Resumable transfers split a file into chunks and track which chunks have been successfully received; when the connection drops, the client picks up from the next unsent chunk instead of restarting at byte zero. The web standard for this is tus.io (an open resumable upload protocol), implemented by SwissTransfer, HexaTransfer, Vimeo, Cloudinary, and many modern transfer services. For downloads, HTTP Range requests (RFC 7233) let browsers and tools like curl or aria2 resume interrupted downloads. Without resumability, a 9.8 GB upload that fails at 9.5 GB costs you the whole thing — with resumability, you lose maybe 50 MB.

The problem with non-resumable uploads

A naive file upload sends the entire file as one HTTP POST request. If anything interrupts the connection — Wi-Fi drop, VPN timeout, laptop sleep, ISP blip — the TCP connection closes and the server discards whatever partial data it had. The client starts over from byte zero.

For a 5 GB upload on a 50 Mbps connection, that's 13 minutes of work thrown away. For a 50 GB upload, it's over two hours. The failure rate of non-resumable uploads on mobile connections is brutal — a 30-minute upload on a 4G connection rarely succeeds on the first try.

How resumable protocols work

Modern resumable uploads work roughly like this:

1. Create: Client sends POST to the server with the file's total size and metadata. Server returns a unique URL for this specific upload and reserves storage.
2. Chunk: Client slices the file into chunks (commonly 5-64 MB each).
3. Upload: Client sends each chunk as a PATCH request with a Content-Range or Upload-Offset header indicating the chunk's position.
4. Acknowledge: Server writes the chunk to storage and confirms the new offset.
5. Resume: If the connection drops, the client sends a HEAD request to the upload URL. The server responds with the current offset (how many bytes it has). The client resumes from that offset.
6. Complete: When the final chunk is acknowledged, the upload is done.

This model is defined by the tus.io specification (version 1.0.0 is widely deployed). Other variants include S3 Multipart Upload (for direct S3 uploads) and Google Cloud Storage Resumable Uploads.

Tus.io: the open standard

Tus ("transloadit upload server") is a free, open protocol maintained by Transloadit. The specification lives at tus.io and is implemented by:

• Client libraries: tus-js-client (browser + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
• Server implementations: tusd (Go reference server), tus-node-server, and many framework integrations
• Commercial services: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, Uppy's companion servers

The protocol is deliberately minimal: four HTTP verbs (POST, HEAD, PATCH, OPTIONS), a handful of headers (Upload-Offset, Upload-Length, Tus-Resumable). This keeps implementations simple and interoperable.

Chunk size decisions

Chunk size trades off resume granularity for HTTP overhead.

| Chunk size | Recovery cost on failure | Overhead | |---|---|---| | 1 MB | Lose ≤ 1 MB | High (many requests) | | 5 MB | Lose ≤ 5 MB | Moderate | | 16 MB | Lose ≤ 16 MB | Low | | 64 MB | Lose ≤ 64 MB | Minimal | | 256 MB | Lose ≤ 256 MB | Negligible overhead, painful if failure |

For stable connections, 32-64 MB chunks maximize throughput. For mobile or flaky Wi-Fi, 2-5 MB chunks recover faster from each failure. Services usually pick a default in the 5-10 MB range as a compromise.

What actually interrupts transfers

Understanding the failure modes helps evaluate whether a service's resume implementation is robust:

• Wi-Fi drops: switching networks, signal loss, router reboot. Very common.
• Laptop sleep: closing the lid on macOS/Windows. The OS pauses network; when you wake, connections often need to re-establish.
• Tab suspension: modern browsers suspend background tabs to save memory. Uploads in a suspended tab may stall.
• ISP/backhaul issues: momentary routing changes, TLS re-handshake required.
• VPN reconnection: VPN clients periodically renegotiate; the TCP connection dies.
• Server-side restarts: the transfer service deploys a new version; in-flight requests fail.
• Cross-origin policy changes: corporate firewalls inspecting traffic sometimes kill long-running connections.

A robust resumable implementation handles all these with the same mechanism: reconnect, HEAD to check offset, resume from there.

Resume for downloads

HTTP Range requests (RFC 7233) power resumable downloads. A server that advertises Accept-Ranges: bytes in response headers supports range requests. Clients can then issue Range: bytes=1000000- to fetch only bytes from offset 1,000,000 onward.

Browsers use this automatically when you hit "Resume" in the download manager. Chrome, Firefox, and Safari all support resume for downloads from compliant servers. Most CDNs (Cloudflare, Fastly, CloudFront) support ranges.

Command-line tools expose more control:

• curl -C - -O url resumes a download from wherever it stopped.
• wget -c url does the same.
• aria2c -c -s 16 url downloads with 16 parallel range-request streams for speed.

Services that support resume

Modern transfer services mostly handle upload resume:

| Service | Upload resume | Download resume | |---|---|---| | SwissTransfer | Yes (tus-based) | Yes (HTTP ranges) | | HexaTransfer | Yes (chunked + tus-compatible) | Yes | | WeTransfer | Yes (chunked uploads) | Yes | | Dropbox Transfer | Yes | Yes | | Google Drive | Yes (resumable upload API) | Yes | | OneDrive | Yes | Yes | | Box | Yes | Yes |

Free tiers sometimes disable resume to encourage paid upgrades, but this is rare in 2026. Older services without resume support are disappearing from recommendation lists because users tire of the failures.

What doesn't automatically resume

Plain HTTP POST uploads in naive applications don't resume. FTP transfers historically vary — some clients and servers support REST (restart) commands, others don't. Email attachments can't be resumed — if a Gmail send fails at 90%, you're restarting.

Torrent-based transfers inherently resume because the torrent protocol tracks which pieces have been verified. This is part of why BitTorrent remained useful for very large distributions even as the web caught up on other metrics.

Resume with end-to-end encryption

Resumable uploads combined with client-side encryption require careful chunking. The file is split into chunks, each chunk is encrypted with AES-256-GCM using a unique IV (initialization vector), and then uploaded. On resume, the client must know which chunks completed and continue from the next one.

Because each chunk is independently encrypted and authenticated (GCM's AEAD mode), partial uploads can't be tampered with. A malicious server that inserts garbage at offset 5 GB would fail authentication when the recipient decrypts — the GCM tag mismatch would be caught.

Implementations like HexaTransfer use per-chunk IVs derived deterministically from a master key and chunk index, so resumption doesn't require storing IVs separately. The decryption side reconstructs them from the same derivation.

Client-side best practices

To maximize resume success:

• Keep the tab active during upload. Browser tab suspension kills in-flight uploads. A "don't close this tab" warning is standard in transfer service UIs.
• Plug into wired network when possible. Wi-Fi drops cause most failures.
• Disable power-saving sleep during long uploads. macOS: caffeinate -i. Windows: the Powertoys Awake utility or power plan changes.
• Don't switch Wi-Fi networks mid-upload. The TCP connection changes IP and dies.
• Let the upload finish before closing the laptop lid. Modern macOS sometimes preserves uploads through brief sleep, but it's not reliable.

Verify on the server side

Some services show incomplete progress bars that don't actually reflect server state. After an upload that survived one or two interruptions, refresh the page and verify the link works — open it in incognito and download a small portion. If the resume worked, the full file will download correctly.

For paranoia-worthy scenarios, compute a SHA-256 hash on the client, upload, and verify by hashing the downloaded file matches. Cryptographic file integrity check takes 10 seconds of CPU per gigabyte and gives absolute certainty.

Verdict

Resumable transfer is a table-stakes feature in 2026 — any service without it is an immediate deal-breaker for files over a few hundred megabytes. Look for tus.io compliance or equivalent chunked-upload behavior. Ensure the service you pick handles interruptions gracefully; test with a deliberate network drop on a small file before committing to a large transfer.

Try it at hexatransfer.com — free, no account, 10 GB max.