What Actually Happens When You Download a File

Click "Download" and a file appears in your Downloads folder a moment later — same as any cloud service. What's different on LifetimeCloud is everything that happens in that moment, none of which involves the server ever having a readable copy of your file.

Step by step

1. Your browser requests the file by ID. The server looks up the stored record and streams back the raw ciphertext — the exact encrypted blob that was uploaded, untouched.
2. The encrypted filename and IV come from your local cache. The server intentionally doesn't send them in the download response headers; your browser already has them from when the file list was loaded, keeping that metadata off the wire on every single download.
3. Your key decrypts the blob locally. Using the AES-256-GCM key derived from your password (see our AES-256-GCM explainer), your browser decrypts the ciphertext into the original bytes, entirely on-device.
4. GCM's built-in integrity check runs automatically. If even a single byte of the ciphertext was altered or corrupted in transit or storage, decryption fails outright rather than silently returning garbage — you'd see an error, not a corrupted file.
5. The browser triggers a normal file save. The decrypted bytes are handed to your browser's standard download mechanism, and the file lands in your Downloads folder exactly as if it came from any website.

What never happens

• The server never decrypts anything to "prepare" the download — it has no key to do so with.
• Nothing is decrypted and stored temporarily on any server in between — the ciphertext goes straight from storage to your connection.
• Your password and derived key never leave your device during this entire sequence.

Download vs. preview — same decryption, different destination

Opening a file to preview it runs through nearly the identical process — fetch ciphertext, decrypt locally — the only difference is where the decrypted bytes go: into a temporary in-memory viewer instead of a saved file. Neither path ever involves the server holding plaintext, even momentarily.

Why this matters for large files

Because decryption happens in your browser rather than on a server, a very large file (a multi-gigabyte video export, for instance) is decrypted using your own device's CPU rather than shared server resources — meaning performance depends on your hardware, not on how busy LifetimeCloud's infrastructure happens to be at that moment. It also means there's no server-side decryption queue that could create a backlog during peak usage.