Downloading

The server's only role in a download is to hand back the encrypted chunks it stored (or fetch them from your storage platform on your behalf). Every step that turns those chunks back into a readable file (decryption, decompression, verification) runs locally. The server never sees a decrypted byte and never sees your passphrase.

The heavy work runs in a pool of Web Workers, off the main thread, so the app stays responsive while it decrypts: even on a multi-gigabyte file. The size of that pool is chosen from your device's CPU and memory rather than being fixed.

1. Fetch. The browser requests the file's encrypted chunks, pulling several in parallel for speed. A dropped connection or slow chunk is retried on its own, and the access token is refreshed mid-download so a long transfer doesn't stall on an expired session.
2. Decrypt & decompress. Each chunk is decrypted with AES-256-GCM using the per-file key unwrapped from your passphrase (or the folder password, for a protected folder), then decompressed with zstd: both in the worker pool, off the main thread.
3. Verify. Once the chunks are reassembled, the file's SHA-256 is compared against the hash recorded at upload. A mismatch fails the download rather than saving a damaged file.
4. Save. Small files are rebuilt in memory and downloaded the usual way; large files are streamed straight to disk as they arrive (below).

For most files the browser rebuilds the whole thing in memory and then saves it. That approach breaks down once a file is larger than a browser tab can comfortably hold, so past roughly a gigabyte, zcrypt streams the download straight to disk instead. You choose where to save it up front (a Save-As prompt), and each chunk is decrypted and written out in order as it arrives, so the whole file never has to sit in RAM at once. This is what makes downloading very large files: on the order of tens of gigabytes, a 25 GB file, say, possible at all.

Streaming to disk uses the browser's File System Access API, which today means a Chromium-based browser; where it isn't available, zcrypt falls back to the in-memory path. If a streamed download fails its integrity check or you cancel it, the partial file on disk is discarded: a corrupt or truncated file is never left committed.

A download can be paused and picked back up: pausing keeps everything decrypted so far (and, for a large download streaming to disk, the open file on disk), and resuming continues from there instead of restarting at chunk zero. A retry after a failure does the same, it continues from what's already done rather than re-fetching the whole file. Pausing is deliberately distinct from stopping: a stop discards the in-progress work, a pause preserves it.

Transient blips are handled for you. A dropped connection, a stalled chunk, or a temporary server error is retried automatically with backoff: on single-file downloads, on bulk ZIP downloads, and on shared-link downloads, so one hiccup over a long transfer doesn't sink the whole file.

Two things guard integrity. First, AES-256-GCM is an authenticated cipher, so a chunk that was altered in storage fails to decrypt rather than producing garbage: a tampered piece is caught the moment it is opened. Second, once every chunk is decrypted and reassembled, the file's SHA-256 is checked against the hash recorded at upload; a mismatch fails the download instead of saving a damaged file. On a streamed download that hash is built up as chunks are written, so the check costs no extra copy of the file.

A file stored inside a password-protected folder is encrypted under that folder's password, not your vault passphrase. Downloading one prompts for the folder password (if the folder isn't already unlocked in this session), and that password is what unwraps the key locally. An unlocked vault alone is not enough to open a protected folder's files.

• •Transfer manager: pause, resume, retry, and track downloads
• •Bulk operations: download many files at once as a ZIP
• •Viewing & previewing. Open files without saving them