To password-protect a download link, set the password when you create the link, then send the password through a different channel from the link itself — a text message or a phone call, not the same email. That separation is the whole point: someone who gets hold of the email alone gets nothing. Pair it with an expiry date and a password turns a link anyone could forward into one that only works for the right person, for a limited time.
I run Yungle, where passwords on transfers are free. The advice below holds for any service.
What a password actually protects against
A download link is a key. Anyone holding it can open the door, and links travel: they get forwarded, pasted into group chats, left in shared inboxes and found in search results for "invoice". A password adds a second thing the person must know.
It protects well against:
- A link forwarded to someone who should not have it.
- A link sitting in an old email that a new person later reads.
- A mistyped recipient address.
It does not protect against a recipient who shares both the link and the password — no technical control stops a trusted person choosing to share. For that, what helps is an expiry date and a receipt telling you who downloaded.
Send the password somewhere else
The most common mistake is putting the password in the same email as the link: "Here are the files, the password is Autumn2026." Anyone who can read that email now has both halves. It is a lock with the key taped to it.
Send the link by email, and the password by another route:
- A text message or messaging app.
- A phone call, for anything properly sensitive.
- A password agreed in advance for a long-running project.
Choose a password that survives being read aloud
Recipients type these on phones, often after hearing them over a call. Very complex passwords get mistyped and cause a round of "it doesn't work". Aim for long and readable rather than short and cryptic: four unrelated words beat eight random symbols, and are far easier to pass on correctly.
Add an expiry, always
A password answers "who can open it". An expiry answers "until when". Together they cover most of what can go wrong with a link:
- The password stops a stranger who finds the link.
- The expiry stops the link working after the job is done, so old copies die on their own.
On Yungle you set a password and an expiry when you send, free, and you can see who downloaded each file and when. If a link goes to the wrong person, you can revoke it immediately rather than hoping.
When a password is not enough
For some files — medical records, legal documents, identity papers — a password on an ordinary link may not match the risk. The service in the middle can still, technically, read an ordinary file: on Yungle every file is always encrypted with its own key, but those keys are held by the service, which is what makes previews and virus scans possible.
For files where even the service must not be able to read them, use an end-to-end encrypted transfer: the key is created in your browser and travels in the link after the #, which is never sent to the server.
One trade-off to know: because the key is in the link, an end-to-end transfer cannot also carry a server-side password or be emailed by the service — you send the link yourself, through a channel you trust. What "end-to-end encrypted" really means goes into when it is worth it.
A quick routine
- Create the link with a password and an expiry date.
- Email the link.
- Send the password by text or phone.
- Check the receipt; revoke if anything looks wrong.
For the full set of habits around sensitive files, read how to send files securely, and for the product side, secure sharing.