How to Send Files Privately Online: What "Secure" Actually Means in 2025

File sharing services put a padlock icon in the address bar and call themselves "secure." The padlock means your connection to their server is encrypted in transit — your file can't be intercepted while it's moving over the internet. That's a real protection and it matters. It is also a very low bar, and calling it "secure" or "private" is misleading in ways that can matter enormously depending on what you're sending.

Here's what the padlock doesn't mean: it doesn't mean the file isn't sitting on the company's servers afterward. It doesn't mean they can't read it. It doesn't mean it can't be subpoenaed. It doesn't mean it won't still be there in three years. It doesn't mean their security posture is sufficient to protect it from a breach. All of those things can be true simultaneously with a padlock in your address bar.

Private file transfer is a multi-dimensional problem. Understanding the dimensions separately is what lets you actually evaluate whether a tool is doing what you think it is.

The Four Things That Need to Be True for a Transfer to Be Private

1. The file can't be intercepted in transit

This is what HTTPS/TLS protects. Your file is encrypted while moving from your device to the server (or to the recipient's device if it's P2P). Anyone intercepting the traffic sees ciphertext they can't decode. This is solved, by default, on every reputable modern file sharing service. It's the starting point, not the finish line.

2. The file can't be read by the service

Most cloud file sharing services can read your files. Google Drive, Dropbox, OneDrive — all of these hold the encryption keys for files stored on their platforms. Encryption at rest means the files are stored in encrypted form on the server, but the service decrypts them as needed. This is different from end-to-end encryption, where only you and your recipient hold the keys and the service is mathematically unable to decrypt the content.

Why does this matter? Because "the service can read your files" means several concrete things: content scanning runs on your documents (Google's terms explicitly permit this), employee access is theoretically possible, legal requests can compel the service to produce readable content, and the service's AI training pipeline may process your data. For a photo of your lunch, irrelevant. For a draft contract, medical records, legal strategy documents, or financial information — very relevant.

End-to-end encrypted file sharing — where the service never holds a plaintext copy — is offered by Proton Drive, Tresorit, and Wormhole. These services genuinely cannot read your files even under court order, because the decryption keys exist only on your devices.

3. The file can't be exposed by a breach

Cloud services are breached. This is not rare or theoretical. Dropbox: 68 million credentials exposed in 2012, not disclosed until 2016. Adobe: 153 million user records in 2013. Yahoo: 3 billion accounts in 2013 (disclosed in 2017). These are not obscure companies with weak security. They're large, well-funded technology organizations with dedicated security teams, and they were still breached at massive scale.

The fundamental reason cloud services are high-value breach targets is that they centralize enormous amounts of valuable user data. When you store your files on Google Drive or Dropbox, your data is pooled with tens or hundreds of millions of other users' data. That pool is the target. Compromise the infrastructure protecting that pool and you get access to everyone's files simultaneously.

P2P transfer eliminates this risk by eliminating the centralized pool. A breach of Zapfile's infrastructure cannot expose user files because user files are never on Zapfile's infrastructure. The only data available to an attacker is connection metadata — IP addresses and timestamps. The files themselves existed only on the sender's and recipient's devices.

4. The file can't be legally demanded from a third party

Under the US CLOUD Act (2018), US-based cloud providers can be compelled to produce user data in response to US government requests, regardless of where the user is located or where the data is physically stored. Google, Microsoft, Amazon, Dropbox, and Box are all US companies. Files stored on their infrastructure are accessible to US legal process.

This is not a theoretical concern. Google alone receives tens of thousands of government requests for user data annually. Their Transparency Report shows consistently high compliance rates. For lawyers handling privileged communications, healthcare providers covered by HIPAA, journalists protecting sources, and businesses handling commercially sensitive information in industries with confidentiality obligations — the CLOUD Act exposure is a real professional risk.

A P2P service that never stores files cannot produce files under a legal request. There's nothing to hand over. This is not a policy statement ("we won't cooperate with requests") — it's an architectural property ("we have nothing to produce").

How to Actually Send Files Privately

For recipients who are available right now

Zapfile is the cleanest solution for immediate private transfer. Both parties open their browsers. The file transfers P2P with mandatory DTLS encryption on the WebRTC data channel — the encryption is specified in the RFC, not a policy choice. Nothing touches any server. When the recipient closes their tab, the connection ends. The link is dead. There is no file on any server anywhere. No breach can expose it because there's nothing to breach.

This works for any file type, any size, on any device with a modern browser. The workflow is genuinely simple: open zapfile.ai, drop the file, copy the link, send it.

For recipients who will download later — and files that aren't ultra-sensitive

WeTransfer is the pragmatic choice. No account required from either party. Files auto-delete after 7 days. The download experience is clean. Files are encrypted in transit but WeTransfer holds them in readable form — so this is Layer 1 and Layer 3 protection (transit encryption, auto-expiry) without Layer 2 (service can't read) or Layer 4 (can't be legally demanded). For a client deliverable, a design file, a photo album — fine. For legally sensitive communications — use a different tool.

For recipients who will download later — and files that ARE sensitive

Wormhole gives you async delivery with genuine E2E encryption. Files are encrypted client-side before leaving your device. Wormhole's servers hold only ciphertext. 10GB limit, 24-hour expiry. No account from either party.

Proton Drive gives you async delivery with E2E encryption and more flexible expiry settings. Swiss jurisdiction, not subject to CLOUD Act. Shared links can have custom expiry dates and password protection. Requires a Proton account to send; recipient needs no account. Free tier is 1GB. For sensitive professional files that need to be accessible for more than 24 hours, this is the strongest option available.

The Metadata Problem Nobody Mentions

Transfer privacy protects the channel. It says nothing about what's embedded in the file itself.

Microsoft Word documents contain the author's name, the names of everyone who edited the document, the full revision history (even if Track Changes is off), comments, and sometimes hidden text from previous drafts. A Word document shared "privately" via an encrypted channel can still reveal who wrote it, who reviewed it, what was changed and when.

JPEG photos contain GPS coordinates (latitude and longitude of where the photo was taken), the device model, the exact time and date, the camera settings. Photo metadata handed over with a "securely transferred" file can reveal where the photographer was, what device they own, and a timestamped record of their location at that moment.

PDFs can contain the original author's name, the software used to create them, creation and modification dates, and depending on how they were generated, metadata from the original document.

Before sending anything genuinely sensitive, strip the metadata. Microsoft Office's Document Inspector (File → Info → Check for Issues → Inspect Document) removes author data, revision history, and comments. Adobe Acrobat's Sanitize Document function removes all metadata from PDFs. ExifTool (free, command line) removes EXIF data from photos. This step is separate from secure transfer — it protects against information leakage through the file itself rather than the channel.

The Practical Default

For everyday file transfers that aren't particularly sensitive, the privacy hierarchy doesn't matter much. A photo of your lunch going to a friend via Google Drive — the CLOUD Act exposure is not a concern you need to spend mental energy on.

For anything that carries genuine confidentiality — client documents, medical information, legal communications, financial records, source code, unpublished work — the question isn't whether to care about privacy but which level of privacy is appropriate. P2P transfer via Zapfile provides architectural privacy guarantees that no cloud storage option can match, because the architecture eliminates the server from the equation entirely. For the specific files where it matters, that's the difference between a privacy policy (a company's promise) and a privacy property (a mathematical fact about how the system works).