You encrypted the file properly. Now the password has to reach someone else, and that is where the whole thing usually falls apart. Send both in the same email and you have done a lot of work for nothing.
The rule underneath everything below: the password must travel a different route from the thing it opens. Everything else is detail.
Why sending passwords over email fails, even in a second email
Email was designed to be forwarded, copied and stored. It does all three well and none of them help here.
A message passes through several servers, each of which may log it. It lands in a mailbox that gets backed up, indexed and synced to a phone. If the account is ever compromised, everything in it is compromised at once — including both of your carefully separated emails.
That is the flaw in the "send it separately" advice. Two emails to the same person are not two channels. They are one channel used twice, and an attacker reading the mailbox does not care which order they arrive in.
Email is fine for the encrypted part. Send an encrypted file or string through it happily, then move the password somewhere else entirely — that separation is the reason to encrypt the message first at all.
Sharing a password with a coworker: the routes that hold up
Ranked by how well they work in practice, not by theory.
A password manager's sharing feature. The best answer when both people have one. The password never appears in a message, access can be revoked afterwards, and there is a record of who has it. Setting it up takes ten minutes and removes the problem permanently.
A phone call. Underrated, immediate, and it leaves no written copy anywhere. You also get to confirm you are speaking to the right person, which no written channel does. Never leave it on voicemail — that turns it into a stored recording.
An end-to-end encrypted messaging app. Signal, or WhatsApp at a push. Genuinely encrypted in transit, and the message still lands on a device that might be unlocked on a desk. Use disappearing messages if the app offers them.
In person. Obvious, unbeatable, rarely available. Worth it for something that unlocks a lot.
Whatever you choose, generate the password rather than inventing one — our a password worth sending tool makes something long enough to be worth all this effort.
One-time secret links explained, and why we do not offer one
These services take your text, give you a URL, and destroy the content after it has been read once. Privnote and its relatives have been doing this for years and they are genuinely useful.
The mechanism is better than it sounds. The well-built ones encrypt in your browser and put the key in the fragment of the URL — the part after the hash symbol, which browsers never send to the server. The operator holds ciphertext they cannot read.
Two caveats they rarely lead with. You cannot verify from outside that a given service does it that way, or that it kept doing it after its last redesign. And "read once" fails against link previews: chat apps and email scanners fetch URLs automatically to build a preview card, which burns the link before your recipient opens it. Both of you then assume the worst.
We do not build one because it would require us to hold something, and holding nothing is the only claim on our tool pages we can prove. That is a real limitation of our approach, not a superiority — whether a browser tool can be trusted goes through the trade properly.
What to avoid, in rough order of how often we see it
- Both halves in one thread. The most common mistake by a wide margin, usually made in a hurry at the end of the day.
- A shared document or spreadsheet. Revision history keeps deleted passwords readable, and the sharing link outlives everyone's memory of it.
- A ticketing system or project tool. Searchable forever, visible to the whole team, and exported in every data migration.
- SMS. Unencrypted between carriers, and vulnerable to someone taking over the phone number.
- A sticky note on the monitor. Still happens. Still works, right up until the office photo goes on social media.
None of these are catastrophic on their own. They become a problem because passwords sent this way sit around for years, long after the reason for sending them has been forgotten.
The part everyone skips: what happens next
Getting the password there safely is half the job. The other half is what the recipient does with it, and you have no control over that.
Tell them what to expect, in the same message as the encrypted file. Which tool opens it, roughly what the output should look like, and that a failure is more likely to be a copy-paste problem than a wrong password. Our opening what they sent you page exists partly for this, because it names the actual fault instead of showing one unhelpful error.
Then close the loop. Ask them to confirm it opened, and change the password afterwards if it protects something ongoing. A password shared once tends to be shared again by the person you sent it to, and rotation is the only thing that fixes that.
A workable default
For most people, most of the time: encrypt the file, email it, phone them with the password. No accounts, no new software, no trusting anyone's server.
For a team that does this weekly, stop improvising and put a password manager in place. The sharing feature solves it properly and the ten minutes pays for itself the first time somebody leaves.
And keep the failure mode in mind. If the password goes missing entirely, the encrypted file is gone with it — what happens if the password is lost is short, and the answer is not the one people hope for.