DeskShuttleA file becomes a numbered set
A long download has an awkward failure mode: a brief interruption can make a large amount of completed work feel wasted. Splitting the file into independently addressable chunks gives the receiver a more precise question to ask: which pieces are still missing?
DeskShuttle’s chunked path uses a chunk size of 16 × 1024 × 1024 bytes: 16 MiB. A 50 MiB file therefore spans four chunks, with a smaller final chunk. Numbered positions matter. Receiving the right bytes in the wrong order is still the wrong file.
Keep the receipts with the bytes
The browser client stores chunk data in IndexedDB and tracks what it has received. On a retry, it can request the pieces it still needs instead of assuming every previous request failed. The server exposes metadata, chunk and hash endpoints for the transfer workflow.
That does not promise recovery after every possible interruption. The session must still be valid, the source must still be available, and browser-held state must still exist. Clearing website data, changing browser profiles or losing access to the phone can remove the conditions that make resume possible. A private browsing session may also have different storage constraints.
A hash answers a narrow question
SHA-256 maps bytes to a fixed-length digest. Compare a received chunk’s digest with the expected value to detect a mismatch; compare the reconstructed file’s digest to check the assembled result. DeskShuttle’s browser implementation includes both chunk-level and whole-file checks.
Change one byte in our tiny demo fixture and the calculated digest changes. This is a real browser calculation, while the animated transfer is a simulation. A matching digest is not a malware scan, an identity certificate or encryption. If the expected digest and file both come through an untrusted channel, a hash alone does not make that channel trustworthy.
The costs remain visible
Chunking does not make browser memory infinite. The client ultimately assembles data for a downloadable file and performs whole-file work. It should not be described as a constant-memory or zero-copy pipeline. Browser storage, available memory and device conditions remain practical limits.
Use the lab to stop a transfer after a few chunks, then resume it. Watch which pieces remain complete. The important result is the recovery model: retain verified progress, request what is missing, and check the final output. The animation deliberately makes no throughput claim.