What a password actually protects against
Share links are protected by being unguessable — a random string with more possible combinations than there are atoms in a sandwich. Nobody is brute-forcing that. The realistic threat isn't guessing, it's forwarding: your recipient shares the link in a group chat, someone new joins the group, or their phone gets passed around. A password turns 'anyone with the link' into 'anyone with the link and the password', and those are different populations.
When a password adds real value
- The link will circulate in a group whose membership changes — class groups, building chats, work channels with joiners.
- Semi-sensitive documents: lease agreements, invoices, medical results going to a family member.
- You can't use one-time download because several people legitimately need the file.
- The recipient's device is shared — a family computer, an office front desk.
When it's redundant
If you set the link to expire after a single download, a password adds little: even if forwarded, the first click consumes it. Same for anything truly non-sensitive — memes don't need keys. And if you're going to paste the password into the same chat as the link two seconds later, you've built a door lock where the key is taped to the door. The password only means something if it travels separately.
How it should work under the hood
When you set a password on a folder or file, the service should never store what you typed. It stores a hash — the output of a deliberately slow function like PBKDF2 applied to your password thousands of times. When someone enters a password at the gate page, the service hashes the attempt and compares. This way even the operator can't recover the original password, and a database leak doesn't leak passwords.
After a correct entry, decent services issue a signed cookie so recipients don't re-type the password on every visit — while the underlying expiry rules of the files stay in force regardless.
How to password-protect a shared folder, by tool
Most tools protect a shared folder by who is signed in, not by a password — so the right method depends on where the files live and who is receiving them:
| Where the files are | How to add a password | Recipient needs |
|---|---|---|
| Windows or Mac, sent as a file | Make an encrypted archive: 7-Zip on Windows (AES-256 ZIP or 7z), or an encrypted disk image in Disk Utility on a Mac | The password and a tool that opens the archive |
| Google Drive | No link passwords: share with specific Google accounts instead of 'anyone with the link' | A Google account you invited |
| OneDrive or Dropbox | Link passwords are offered on paid plans, under the link's settings | The password |
| A folder link here | Set a folder password on the [multiple-file upload page](/bulk/) before uploading | The password — no account, no app |
An encrypted archive is the only option that protects the file itself wherever it ends up, but it's the most work for the recipient, especially on a phone. A password-protected link keeps previews and works in any browser; see the password-protected folder page for how it works here.
The second-channel rule, and choosing something typeable
Send the link where the content will live (chat, email) and the password through a different channel: a voice call, an SMS, a message on another platform. For the password itself, favor four or five common words over symbol soup — 'harbor-mango-tulip' beats 'H@rb0r!' because people can say it aloud and type it without errors. Combine it with a deadline: a password that expires with the link needs none of the rotation ceremony of a real credential.