How to Transfer Files Without Storing Them Online: The Case Against Permanent Cloud Copies

There is a detail about cloud-based file sharing that most people have never consciously considered: every file you have ever "shared" via Google Drive is still there. Right now. In your Drive. With an active link that still works. Unless you deliberately deleted it and revoked access — which most people never do — every birthday photo, every client deliverable, every contractor asset, every document you "temporarily" shared is sitting in permanent cloud storage, accessible to anyone who has the URL, consuming your storage quota, and subject to whatever Google's current terms of service permit them to do with it.

This isn't a worst-case scenario. It's the default behavior of every cloud storage platform used as a file delivery mechanism. The storage is the point of cloud storage — files are supposed to persist. But when you're sending a file to one person who will download it once and never need it again, persistence is a bug, not a feature. You've created a permanent online copy of something that only needed to exist long enough to be delivered.

This guide is about methods that deliver files without creating permanent server-side copies. The distinction matters more than most people realize.

Why Permanent Storage Creates Problems You Don't Anticipate Until They Occur

The forgotten link problem. A Google Drive link shared in an email in 2021 is still functional in 2025. The email thread it was shared in may have been forwarded to people you didn't intend to have access. The recipient may have shared the link with colleagues. If you've ever changed jobs, divorced, had a professional relationship sour, or simply lost track of what you've shared — there are files out there accessible to people you've long since stopped trusting with them. This isn't hypothetical. It's the mechanical outcome of using a permanent storage system for temporary file delivery.

The breach liability window. The longer a file sits on a cloud server, the longer its exposure window to a breach. A file that's on a server for 7 days has 1/52nd the annual breach exposure of a file that's on a server permanently. Cloud breaches aren't rare — Dropbox lost 68 million user credentials in a breach disclosed years after the fact, Capital One exposed 100 million records from a misconfigured AWS server. Every day a file sits on a cloud server is a day it's in the breach exposure pool.

The storage cost spiral. Google's 15GB free tier is shared across Drive, Gmail, and Photos. For anyone who regularly shares files via Drive, that quota fills with transfers that were never meant to be permanent. I know people paying for Google One storage not because they need to store things, but because years of "temporary" shares filled their free quota with files they never go back to. You're effectively paying a monthly subscription to store a graveyard of one-time file deliveries.

The content analysis ongoing exposure. Google's Terms of Service permit scanning and analysis of Drive content. A file that stays in Drive for three years has been available to Google's content analysis systems for three years. A file that was transferred P2P and never touched any server was available to no external content analysis for zero seconds. The privacy exposure scales directly with storage duration.

The Spectrum of "Temporary" Storage: What Each Level Actually Means

Not all storage is the same. It's worth being specific about what different tools actually provide, because "temporary" covers a wide range.

Zero storage — P2P transfer. The file never touches any server. Zapfile uses WebRTC to create a direct connection between your browser and the recipient's browser. The file travels encrypted from your device to theirs. Zapfile's infrastructure facilitates the connection but never receives the file bytes. When you close your browser tab, the link is dead — not because the file was deleted, but because there was never a file stored anywhere to keep the link alive. This is the strongest possible position: no server-side copy at any point, no window of exposure, no cleanup required.

Session-linked storage — some P2P relay services. Some P2P tools briefly relay file data through servers to handle NAT traversal when direct connections can't be established (this is the TURN relay in WebRTC). The file passes through a relay server in memory but isn't stored to disk. Exposure window: the duration of the transfer, typically seconds to minutes. For most practical purposes, this is equivalent to zero storage from a privacy standpoint.

Short-term encrypted storage — Wormhole. Files are encrypted client-side before upload. Wormhole's servers hold only ciphertext — they cannot read your files. Auto-expires after 24 hours. No account required. 10GB limit. Good for: sensitive files that need a window of hours for the recipient to download, where zero-storage P2P isn't feasible because both parties can't be online simultaneously.

Short-term plaintext storage — WeTransfer. Files are stored on WeTransfer's servers in readable form and auto-deleted after 7 days. No account required from recipient. Clean download experience. 2GB free limit. Good for: standard file delivery where the 7-day window is convenient and E2E encryption isn't required. Meaningfully better than Google Drive for one-time transfers because the file actually goes away.

Medium-term storage — Smash. No size limit, 14-day expiry, no account required. Slower download speeds on the free tier. Good for: large files that exceed WeTransfer's 2GB limit and where a two-week recipient window is needed.

Permanent storage — Google Drive, Dropbox, OneDrive. Files persist until manually deleted. Designed for ongoing access, collaboration, and storage. Appropriate when those are the actual requirements. Inappropriate as a default for one-time file delivery.

The Practical Decision Tree

Before any file transfer, one question determines which tool is correct: does this file need to be accessible after the recipient downloads it?

If no — single recipient, downloads once, no ongoing access — then permanent cloud storage is actively wrong for this use case. The question becomes: is the recipient available right now, or do you need async delivery?

Available now: use Zapfile. Zero server storage, no accounts, no size limit, direct P2P. The link expires when you close your tab. Nothing to clean up.

Available within 24 hours + file is sensitive: use Wormhole. E2E encrypted, 24-hour auto-expiry, no accounts.

Available within a week + standard file: use WeTransfer. Clean, no accounts from recipient, 7-day auto-expiry, 2GB limit.

Large file, async, no size limit needed: use Smash. 14-day expiry, no size limit.

If yes — multiple people need ongoing access, or the file needs to be revisited — then cloud storage is doing its actual job. Use Google Drive deliberately, with appropriate sharing settings and an actual plan for revoking access when it's no longer needed.

The Audit Most People Have Never Done

Open your Google Drive right now and sort by "Last modified" ascending. You will find files from years ago with "Shared" icons indicating they have active sharing links. Some of those files you'll recognize. Some you won't. Most of them you never intended to be permanently accessible.

The same audit applies to Dropbox shared links, iCloud shared links, and WeTransfer if you have a paid account with extended retention. Every "quick share" that wasn't followed by explicit cleanup is still accessible somewhere.

The habit that prevents this accumulation isn't more diligent cleanup — it's using tools that clean up automatically. Zapfile doesn't require cleanup because there's nothing to clean up. WeTransfer cleans up in 7 days without any action from you. These tools solve the problem structurally rather than relying on discipline you may or may not apply consistently under pressure.

The One Thing Cloud Storage Gets Right That P2P Doesn't

Asynchronous delivery is cloud storage's genuine advantage over P2P for file transfer. The recipient doesn't need to be online when you send. The file is available whenever they get to it. For international transfers across time zones, for non-technical recipients who may not check immediately, for files that need to be accessible for several days — cloud storage solves a real problem here.

The solution isn't to abandon cloud storage for async delivery. It's to use cloud storage with automatic expiry rather than permanent retention. WeTransfer's 7-day auto-expiry gives you the async delivery benefit of cloud storage without the permanent copy downside of Google Drive. Wormhole adds E2E encryption on top of auto-expiry for cases where that matters. These tools provide the async delivery that P2P can't, without the indefinite retention that Google Drive defaults to.

The goal isn't to eliminate cloud storage from file transfer. It's to stop treating permanent storage as the default when temporary delivery is all that's actually needed.