How to Send Files Securely

You have a contract, a tax return, a medical record. You need it on someone else's screen within the hour. If you want to know how to send files securely, the answer is shorter than most guides make it: encrypt the file before it leaves your device, send it through a channel that never holds the decryption key, and deliver that key through a completely separate path. Everything else is detail. Here is the detail.

Key Takeaways

• Standard email encrypts the connection, not the file. Once the attachment lands in a recipient's inbox, it sits there in plaintext, forwardable, unrevocable, forever.
• The single principle that separates amateur from professional file-sharing: never let the file and the password travel the same path. This is called out-of-band key delivery.
• You can do this right now, with no new tool, using a password-protected AES-256 archive (7-Zip is free) and sending the password over a different channel like a phone call or a Signal message.
• "Encrypted" and "confidential" are not the same thing. Many services encrypt your file in transit but hold the decryption key themselves. Zero-knowledge means even the service cannot open it.
• The leak you forgot about: pasting the document into a consumer AI chatbot to summarize it is, from a security standpoint, the same as emailing it to a stranger. A federal court ruled in 2026 that documents created with a consumer AI platform lost privilege protections entirely.

Why Is Regular Email a Bad Way to Send Sensitive Files?

Because email encrypts the connection between mail servers (TLS in transit), not the file itself once it arrives. Your contract sits in the recipient's inbox as a readable attachment, copyable, forwardable, with no access control after sending, no audit trail, and no way to revoke it. If their account is compromised six months from now, your file is part of the haul.

Standard email is considered one of the least secure channels for transmitting confidential documents. It was designed for convenience in the 1990s. The threat model it was built against is packet sniffing on the wire, which TLS handles fine. The threat model you actually face in 2026 is credential theft, inbox compromise, accidental forwarding, and indefinite retention on servers you do not control.

People know this intuitively. They still attach the PDF because the alternative feels complicated. It does not have to be.

What Is the One Principle That Actually Matters?

Out-of-band key delivery. That is the whole game.

The idea: send the encrypted file through one channel and the password or decryption key through a completely different channel, so that an attacker who intercepts one path still cannot access the content. If you email a password-protected ZIP and then email the password in the next message, you have accomplished nothing. Same channel, same compromise surface. If you email the ZIP and call the recipient with the password, now an attacker needs to compromise both your email and your phone line. The cost of attack just doubled, at minimum.

This is not a feature list. It is a mental model. Every tool decision, every workflow choice, collapses into one question: do the file and the key ever travel together?

How Do I Send a File Securely Right Now, Without Installing Anything New?

You need three things: a file archiver that supports AES-256 encryption, a strong password, and a second communication channel. Here are the steps.

Step 1: Create a password-protected archive

Download 7-Zip (free, open source, available on every major OS). Right-click your file, select "Add to archive," set the archive format to 7z or ZIP, choose AES-256 as the encryption method, and enter a password. Use a password of at least 20 characters. A passphrase works well: four or five unrelated words separated by a punctuation mark. Do not reuse a password you use anywhere else.

Step 2: Send the archive through your normal channel

Email it. Upload it to a shared drive. Use whatever transfer mechanism the recipient expects. The file is encrypted. The contents are unreadable without the password. The transport channel matters less when the payload is independently protected.

Step 3: Deliver the password out-of-band

Call the recipient and read the password aloud. Send it over Signal or another end-to-end encrypted messenger. Text it (better than emailing it, worse than Signal). The point is that the password never touches the same channel as the file. If your email is compromised, the attacker gets an encrypted blob and no key.

This approach requires no subscription, no account creation, no new software beyond a free archiver. It works for a contract you need to send in the next ten minutes. It is not elegant. It is effective.

What Is the Difference Between "Encrypted" and "Zero-Knowledge"?

True security separates two layers: encryption at rest and in transit (AES-256, TLS) versus zero-knowledge architectures where even the service provider cannot decrypt the file. Most mainstream cloud storage services handle the first layer. Your file is encrypted on their servers, yes, but they hold the key. They can read it. They can be compelled to read it. A breach of their systems exposes your plaintext.

Zero-knowledge means the encryption and decryption happen on your device, before the file ever reaches the service. The provider stores ciphertext and never possesses the key. This is a meaningful architectural difference, not a marketing checkbox. When a service says "encrypted," ask: encrypted by whom, and who holds the key?

What About Secure File-Sharing Tools?

The 2026 landscape has converged. Nearly every purpose-built secure file-sharing product now offers the same baseline: client-side AES-256 encryption, password-protected expiring links, and audit trails. Products like Tresorit, Internxt, SendMeSafe, Strac, Alkmist, and Papermark all lead with roughly the same feature set. The differences are in pricing, UX, integration with existing workflows, and whether the zero-knowledge claim is structurally enforced or just stated.

When evaluating any of these tools, ask three questions:

1. Does encryption happen on my device before upload, or on the provider's server after upload?
2. Can I set an expiration date and download limit on the link?
3. Is there an audit log showing who accessed the file and when?

If the answer to the first question is "on their server," they hold your key. Everything else is window dressing on a trust-me architecture.

How Does Sending a File to an AI Chatbot Count as "Sending"?

It counts completely, and this is the part most how-to guides skip.

You receive a 40-page contract. You want a summary. You paste the full text into a consumer AI chatbot. You have now transmitted that contract to a third-party server, where it may be logged, reviewed by humans, and used for training. One 2025 study found that sensitive data made up 34.8% of employee inputs into chatbot-style AI tools, up from 11% in 2023. The trajectory is steep and the awareness is low.

Contracts are considered the single highest-risk document type to upload to a general AI tool because they combine pricing, terms, counterparty identities, and intellectual property in one file. A lease with your Social Security number on it. An NDA with the acquisition target's name in it. A services agreement with your hourly rate. All of it, pasted into a text box connected to infrastructure you do not control.

This is not theoretical. In February 2026, a federal judge in the Southern District of New York ruled in United States v. Heppner that documents a defendant created using a consumer AI platform were not protected by attorney-client privilege or work-product doctrine. The reasoning: by submitting the material to a third-party commercial service, the defendant had waived confidentiality. The file left the privilege boundary the moment it hit the chatbot's API.

Australia's privacy regulator has recommended that organizations avoid entering personal or sensitive information into publicly available generative AI tools. The guidance is getting more explicit everywhere because the risk surface is real and growing.

So if you need an AI to help you understand a document, use one that is architecturally designed not to retain or train on your input. At Selina, files transferred through SelinaSEND are zero-knowledge encrypted, meaning we cannot read them. Memory works differently (it is encrypted at rest, not end-to-end encrypted, because a portion of each request reaches a frontier provider at inference), but file transfers are a separate, tighter system. If the document is sensitive enough that you would not email it unencrypted, it is sensitive enough that you should not paste it into a general-purpose chatbot either.

What If I Need to Send Medical Records?

Then the stakes are higher and the regulatory exposure is specific.

2024 was the worst year on record for large healthcare breaches, with approximately 289 million individuals affected, driven largely by the Change Healthcare ransomware attack that exposed roughly 192.7 million people. That single incident accounted for about two-thirds of all healthcare exposures that year.

Healthcare breaches cost an average of $7.42 million in 2025, the highest of any industry for fourteen consecutive years. They take an average of 279 days to identify and contain. That is nine months of exposure before anyone even knows the data is out.

Updated HIPAA civil penalty amounts took effect January 28, 2026. If you send a patient's records via unencrypted email and something goes wrong, the penalty tiers are not abstract. They are dollar figures with your name on them.

For medical records specifically:

• Use a HIPAA-compliant file transfer service that provides a Business Associate Agreement (BAA). If they will not sign a BAA, do not use them.
• Encrypt the file before upload. Do not rely solely on the transfer service's encryption.
• Deliver the access password out-of-band. Phone call to the recipient's verified number. Not a text to whatever number is in the chart.
• Set the link to expire within 24 to 72 hours. Medical records do not need to be downloadable indefinitely.
• Log the transfer. You need a record of who sent what, to whom, and when, in case of an audit.

One note on breach statistics: HIPAA Journal has noted that OCR was slow to publish new breach-portal entries in 2026, likely due to the 43-day federal shutdown from October through November 2025. If someone tells you healthcare breaches are declining in 2026, the reporting data is distorted. Be skeptical.

What About Tax Documents?

Tax returns contain your Social Security number, your income, your employer, your bank account (if you set up direct deposit for a refund), and in some cases your dependents' Social Security numbers. A single 1040 is an identity theft kit.

The practical steps are the same as above, but with one addition: verify the recipient. Tax scams that impersonate CPAs or tax preparers and request documents via email are common during filing season. Before you send anything, confirm the request through a channel you initiated (call the firm's published phone number, not the number in the email) and confirm the specific secure method they use to receive documents. Most legitimate tax preparers now use client portals with encrypted upload. If yours is asking you to email a PDF of your W-2, find a new preparer.

How Do I Verify That a Transfer Actually Worked?

This is the part that does not make it into most guides because it is boring and operational. But if you are sending something that matters, you need to close the loop.

After sending an encrypted file:

1. Ask the recipient to confirm receipt through the same out-of-band channel you used for the password.
2. Ask them to confirm that the file decrypted successfully and is not corrupted.
3. If the transfer service provides an audit log, check it. Verify that the download count matches expectations. One download from the expected IP region. Not four downloads from three countries.
4. Once confirmed, delete the file from the transfer service if the platform allows it. Do not leave encrypted blobs sitting on third-party infrastructure indefinitely. Encryption can be broken given enough time and future compute. Files that do not exist cannot be decrypted.

I have a small war story on verification from building Selina's encrypted-at-rest system. When your data is encrypted before storage, the database is no longer the source of truth for debugging. A content column can read as empty or as random bytes and still decrypt to perfect data through the application's own decrypt path. We learned to debug through the application's decrypt layer on the specific rows under investigation, never by reading raw columns. The lesson generalizes: if you encrypt a file and the recipient says "it's empty," the file might be fine. The problem might be the decryption step. Always check the decrypt path before assuming the transfer failed.

What Is a Reasonable Checklist Before Hitting Send?

1. Is the file encrypted independently of the transport? (Not just TLS in transit, but AES-256 or equivalent applied to the file itself.)
2. Am I sending the password through a different channel than the file?
3. Does the link expire? Is there a download limit?
4. Have I verified the recipient's identity through a channel I initiated?
5. If this is a regulated document (health, financial, legal), does the transfer method satisfy the applicable regulation? HIPAA requires a BAA. Financial services may require specific retention and audit controls.
6. Am I about to paste this document into a consumer AI tool to analyze it? If so, stop. Use a tool designed for confidential input, or redact the sensitive fields first.

What Should I Stop Doing Immediately?

Three things.

Stop emailing unencrypted attachments. This is the default behavior for most people and it is the least secure option available. Standard email only encrypts the connection, not the file itself once it lands in an inbox. Every unencrypted attachment you have ever sent is sitting in someone's inbox right now, waiting for an account compromise.

Stop sending the password in the same email as the file. This is security theater. An attacker who has access to the email thread has access to both. Two channels or nothing.

Stop pasting sensitive documents into general-purpose AI chatbots. You would not email your tax return to a stranger and ask them to summarize it. Pasting it into a consumer chatbot is structurally the same action, with the additional risk that the content may be used for model training. The more you reveal to AI, the greater the privacy risk, and the legal system is beginning to agree.

Does Any of This Matter If I Trust the Recipient?

Yes, because the threat model is rarely about the recipient. It is about every system between you and them, every system that stores a copy after delivery, and every future compromise of any of those systems. You trust your accountant. You do not trust every mail server between your outbox and their inbox. You do not trust that their email provider will never be breached. You do not trust that the laptop they read it on will never be stolen.

Encryption is not about distrust between humans. It is about limiting the blast radius when infrastructure fails, because infrastructure always fails eventually.

The Short Version

Encrypt the file on your device. Send it. Send the password through a different channel. Verify receipt. Delete the remote copy. Do not paste the contents into a consumer AI tool.

That is the entire protocol. The tools change every year. The principle does not. The file and the key never travel together.

Start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io