How to Share Files Securely: A Practical Guide

"Just send it on Slack" works fine for cat memes. For anything you wouldn't paste in a public square, you need a real workflow. This guide is the practical, non-paranoid version — enough to make sensible choices without becoming a full-time security person.

Decide what you're protecting

Start here. Security choices that don't map to a real risk are theater. Ask yourself:

• Who could read this file and cause harm? A competitor, a stalker, a government, your boss?
• What's the worst case if it leaks? Embarrassment? Lawsuit? Physical danger to a source?
• How long is it sensitive? A week (campaign launch)? A year (contract)? Forever (medical history)?

Your answers determine which trade-offs are worth making. A wedding photo to your in-laws doesn't need the same precautions as a whistleblower drop.

The three tiers of "secure sharing"

Tier 1 — casual

Not sensitive, but you'd rather it stay private. Examples: family photos, project drafts, restaurant receipts.

What's enough:

• HTTPS to your service.
• A non-creepy vendor (avoids "free service that monetizes your content").
• An expiry or download cap, so old links don't linger.

Most decent services meet this bar.

Tier 2 — confidential

You'd be upset if a stranger read it, and possibly liable. Examples: legal contracts, financial records, ID scans, NDA-protected work.

What's needed:

• End-to-end encryption — server cannot read the file.
• A short expiry (7–14 days).
• A download cap matching the expected recipient count.
• Sending the link through an account-bound channel (your email, your Signal, etc.) so receipt is traceable on your end.

This rules out plain Dropbox, Google Drive, plain email. Or WeTransfer. You want a real E2EE service.

Tier 3 — high-sensitivity

Source protection, whistleblower-class material, or anything where leakage has serious consequences.

What's needed:

• End-to-end encryption (non-negotiable).
• Anonymous upload — no account, no email, no identity tie.
• Tor or VPN to obscure the upload's origin network.
• Stripped metadata in the file itself (EXIF, document author info, etc.).
• One-time download cap.
• Tight expiry (24h if practical).
• Link transmission through an out-of-band channel (e.g., Signal, not the source's regular email).

For the highest tier, consider SecureDrop or similar dedicated tools. More on that here.

How to evaluate a file-sharing service

Five questions to ask before trusting a service with anything tier 2 or above:

1. Can they read my file? Read the privacy policy. Search for "scan", "analyze", "improve services". If those words touch user content, they can read it.
2. Where is encryption happening? Server-side encryption (most services) means they hold the keys. Browser-side encryption (Zippd, Mega, Proton) means they don't. More here.
3. Does the share URL have a fragment? Real E2EE services put the key in the URL after #. URLs without a fragment imply server-side decryption.
4. What happens if I lose the URL? If the service can recover the file, they have your key. If "lose URL = lose file," they don't.
5. How long do files actually persist? Some services keep "expired" files in backups or cold storage. Check the data retention disclosure.

Common mistakes

Pasting the URL in a public channel

The whole point of end-to-end encryption is that only people with the URL can decrypt. If you post the URL in a public Notion, Discord channel, or GitHub gist, you've defeated it. The link is the key.

Forgetting metadata

The file content might be safe, but PDFs and photos often contain author info, edit history, GPS data. Strip with mat2, exiftool, or by re-exporting through a clean editor before uploading.

Using the same channel for the URL and the password

If you use a service that splits the file from a separate password, sending both through the same email or chat defeats the protection. Use one channel for the URL, a different one for the password (or, in Zippd's case, split the URL itself).

Trusting "we encrypt at rest"

At-rest encryption only protects against stolen drives. The vendor still has the keys. Insist on end-to-end for anything sensitive.

Long retention by default

Many services keep files until you manually delete. That's a long exposure window. Prefer services with default expiry. More on expiry.

A step-by-step secure send

Worked example — sending a legal contract:

1. Sanitize: strip the document's metadata (Acrobat has a "Remove Hidden Information" tool).
2. Upload to a service with end-to-end encryption (the homepage works).
3. Set max downloads to 2 (counterparty + their lawyer, perhaps).
4. Leave default expiry (30 days for registered, plenty for a signing window).
5. Copy the full share URL — including the #k=... part.
6. Send through your normal channel (email, project tool).
7. Tell the recipient to download promptly and save locally.
8. Let the link expire on its own.

FAQ

How do I share with someone who's not tech-savvy?

End-to-end services that look like normal file sharing (Zippd, the late Firefox Send) are designed for non-experts. The recipient clicks a link, clicks download. The encryption is invisible.

What about password-protected zip files?

Better than nothing, but ZIP encryption is older and weaker than AES-256-GCM. The bigger issue: the password has to travel somehow, and people often send it in the same email as the link.

Is email itself "secure enough" sometimes?

For tier 1 stuff, sure. For anything sensitive, no — emails sit in inboxes forever, often in providers that scan content. Send via a real E2EE service and include only the link in your email.

Should I encrypt files locally before uploading?

If the service is E2EE, you're double-encrypting, which doesn't add real security but adds friction. If the service isn't E2EE, local encryption helps but key exchange becomes your problem.

Send something now

Pick a file you'd want kept private. Upload it on the homepage and walk through the flow yourself. The whole guide above takes about 30 seconds to actually do.