How to Send Confidential Files Online Securely: A Practical Guide for 2025

At some point you have to send something sensitive online. A contract to a client. Tax documents to your accountant. Medical records to a specialist. Source code to a contractor. HR files to a new hire. Financial statements to a lender. These are files with real consequences if they reach the wrong hands — professionally, legally, or personally. And the overwhelming majority of people send them via the same channels they use for everything else: email, Google Drive, Slack — none of which were designed with confidential document transfer as the primary use case.

This guide is about doing it correctly. Not in a paranoid, threat-model-everything way. In a "here are the specific things you actually need to think about, and the specific tools that actually address them" way.

Step One: Define What You Are Actually Protecting Against

Security requirements depend entirely on your threat model. The right tool for a freelancer sending a client invoice is different from the right tool for a lawyer sending privileged communications, which is different from the right tool for a healthcare provider sharing patient records. Being explicit about the threat prevents both under-protecting (using Google Drive for something that deserves E2E encryption) and over-engineering (adding Tor layers to a client design file).

Basic confidentiality — most business documents fall here: The file is sensitive enough that you don't want it accessible via a permanent public link or visible to random third parties, but it doesn't carry formal legal privilege or regulatory obligations. Contracts, proposals, financial projections, internal strategy docs. The risk is careless exposure — a Google Drive link set to "Anyone with the link" that gets forwarded, a file still accessible years later via a link you forgot you made. The solution is mostly process discipline plus auto-expiring delivery.

Protection from content analysis — IP, legal work, creative work in progress: The file contains information you don't want scanned, categorized, or analyzed by cloud service AI systems. Unreleased product information, legal strategy, creative work before publication. The risk is the platform itself — not an external attacker, but the service doing what its own terms of service permit. Google Drive's terms permit content analysis of uploaded files. The solution is end-to-end encryption or P2P transfer, either of which prevents the service from ever having plaintext access.

Protection from legal process — privileged communications, journalism, healthcare: The file is subject to attorney-client privilege, confidentiality obligations, source protection, or patient privacy. The risk is that a government legal request to a US-based cloud provider could compel disclosure without your knowledge. The CLOUD Act (2018) makes this possible for any file stored on US cloud infrastructure regardless of where you are located. The solution is E2E encrypted storage with non-US jurisdiction (Proton Drive, Swiss FADP) or P2P transfer that leaves no copy with any service.

Protection from a targeted attacker — high-value negotiations, source protection: Someone is actively trying to intercept this specific transfer. The risk is interception, not passive storage risks. The solution adds VPN or Tor to the P2P layer for IP masking, plus file-level encryption at rest for defense in depth.

The Tools, Matched to Those Threat Levels

Zapfile for immediate transfer with zero server footprint

Zapfile handles levels 1 through 3 when both parties are available simultaneously. The file goes P2P via WebRTC — Zapfile's infrastructure never receives file content. No content scanning possible. No breach exposure possible for file contents. No legal request compliance possible for file contents. The link expires when you close your tab. Nothing to clean up.

The limitation: requires both parties online simultaneously. Best for: immediate client deliverables, legal documents, financial files, anything where you're coordinating the transfer in real time.

Proton Drive for async transfer with E2E encryption and Swiss jurisdiction

Proton Drive implements genuine end-to-end encryption. Files are encrypted in your browser before upload using keys only you hold. Proton's servers hold only ciphertext and cannot decrypt your files even in principle, not just as a matter of policy. Shared links support password protection and custom expiry dates. Swiss jurisdiction — subject to the Swiss Federal Act on Data Protection (FADP), not the US CLOUD Act. Free tier provides 1GB; paid plans from €3.99/month for 200GB. Requires a Proton account to send; recipients need no account to download.

Best for: sensitive documents needing async delivery, legally sensitive communications, anything where Swiss jurisdiction outside US CLOUD Act reach matters.

Tresorit for regulated industries requiring compliance documentation

Tresorit is designed specifically for regulated-industry professional use. ISO 27001 certified, SOC 2 Type II certified, GDPR and HIPAA-ready, zero-knowledge architecture. Provides detailed per-file access audit logs — who opened, when, from which IP. Link expiry, download count limits, post-delivery revocation. Plans start at €10/user/month.

Justified cost for law firms, healthcare practices, financial services, and any organization where compliance certification and documented audit trails are requirements, not nice-to-haves. Not justified for basic business use where Zapfile or Proton Drive are sufficient.

WeTransfer for basic confidentiality with no compliance requirements

WeTransfer doesn't offer E2E encryption — files are server-readable. But it does offer 7-day auto-expiry, no account required from either party, and a clean professional download experience. For files in the "basic confidentiality" category where you want automatic cleanup but don't have E2E requirements, it's meaningfully better than Google Drive: auto-expiry instead of permanent storage, no content accumulation, no active link after a week.

The Pre-Transfer Checklist That Most People Skip (and Shouldn't)

The transfer channel is only one part of the security picture. These steps happen before you choose a tool and matter as much as the tool choice.

Verify recipient contact information through a separate channel. One wrong character in an email address sends a confidential document to a stranger. One compromised email account means you're sending to an attacker who controls a legitimate contact's inbox. For sensitive files, confirm the email address or verify the recipient is the right person via a quick phone call or text before sending. This sounds obvious. It prevents a non-trivial percentage of real-world data exposure incidents.

Strip file metadata before sending. Microsoft Word documents carry the author's name, the names of everyone who edited the document, full revision history (even with Track Changes off), comments, and the original file path from the author's machine. A confidential legal strategy document emailed "privately" can still identify every lawyer who touched it, all previous drafts including deleted text, and the folder structure on the firm's internal server. Fix this: File → Info → Check for Issues → Inspect Document → Remove All.

PDF files carry creator name, creation date, software used, and often embedded content from the source document. Use Acrobat Pro → Tools → Redact → Sanitize Document, or the free version's Properties panel to clear basic fields.

Photo EXIF data includes GPS coordinates, device model, exact timestamp, and sometimes the photographer's name if set in camera settings. A photo you send as evidence, documentation, or in a sensitive personal context is a record of where you were standing at the moment you took it. Remove with ExifTool: exiftool -all= filename.jpg. iOS Photos has a "Remove Location" option in the share sheet but it only strips GPS, not the full EXIF record.

Split the access channel from the credential channel. If you're using a password-protected Proton Drive or Tresorit link, send the link via email and the password via text message or phone call. An attacker who intercepts your email gets a link to an encrypted file they cannot open. Both the link channel and the password channel would need to be compromised simultaneously for the protection to fail.

Confirm receipt explicitly. Don't assume delivery. A quick "did you get the contract?" closes the loop, lets you know if a resend is needed, and creates a clear record that delivery occurred. For P2P transfers via Zapfile, transfer progress is visible in real time — you can see the bytes moving and know when it's done.

The Most Common Mistakes

Forwarding. Your recipient downloads via a secure channel and then forwards the file as an email attachment. The file that left your hands securely now lives in two people's inboxes and their mail server archives. You cannot control what happens to a file after delivery. Reduce this risk by explicitly asking recipients not to forward sensitive files, and by choosing tools with access revocation capabilities for high-stakes transfers.

Using personal accounts for professional transfers. Sending client contracts from personal Gmail, receiving sensitive files to personal Dropbox. Personal accounts lack organizational security controls, IT oversight, and appropriate retention policies. Files received in your personal Dropbox sit there indefinitely outside any business security framework.

Labelling something "secure" because it uses HTTPS. HTTPS/TLS protects the connection between your browser and the server. It says nothing about what the server does with the file after receiving it. A service can use HTTPS and still store your file permanently, scan it for content, and produce it under legal compulsion. The padlock icon is a necessary condition for transit security. It is not a sufficient condition for confidentiality.

The One Question to Ask Before Every Sensitive Transfer

Could this file's exposure cause real harm — professionally, legally, or personally?

If yes: use P2P (Zapfile) for immediate delivery, or E2E encrypted cloud (Proton Drive, Tresorit) for async delivery. If unsure: treat it as yes. If clearly no: WeTransfer with its auto-expiry is probably sufficient.

The bar for "could cause real harm" is lower than most people set it. A client contract contains pricing competitors could use. A design brief contains unreleased product information. A referral letter contains personal information about a real person who didn't consent to permanent accessibility via a Google Drive link. Most files called "confidential" deserve more protection than a non-expiring Drive link provides. The tools to give them that protection are free and no harder to use.