How do I share a file so only the right person can open it?
The default sharing setting on every cloud service is convenience, not privacy. What the settings actually mean, which to use when, and how to take access back once a link has escaped.
- Difficulty
- beginner
- Time
- 20 min
- Read
- 7 min
- Safety
- caution
Short answer
Share with named people wherever the recipient has an account — the only setting that genuinely restricts who can open it, because access is checked against a sign-in rather than against knowing the address. Anyone with the link is a public address that happens to be hard to guess, right only for things you would not mind a stranger seeing. Set view rather than edit unless someone must change it, add an expiry where offered, and remove the share when the job is done.
Almost nothing escapes from cloud storage by being hacked. It escapes by being shared with a setting nobody read, sent to one person, and then forwarded. Every major service defaults towards the option most likely to work first time — a link anyone can open — because the alternative sometimes fails and generates support requests, and a share that fails is a worse experience than one that works too well. That trade-off is reasonable from the service's point of view and it means the safe setting is the one you have to choose deliberately. There are only about five decisions here, they are the same on every service under different names, and knowing them takes this from a guess to a routine.
Safety
Step by step
- Understand the fundamental split: who, versus what they can do.Every sharing dialogue asks two separate questions. Who can open this — anyone with the address, anyone signed in to your organisation, or specific named people. And what can they do once in — view only, comment, or edit. These are independent, and people routinely get the second right and the first wrong.
- Prefer named-people sharing, and understand why it is different in kind.Sharing with a named account means the service checks who is signed in before it opens the file. Forwarding the link to someone else does not give them access; they are simply refused. That is a genuine access control rather than an obscure address, and it is the only option in this list that survives the link being passed on.
- Use anyone-with-the-link only for material you would not mind being public.It is a good choice for a holiday photo album, a document for a large group, or something being sent to someone with no account. It is the wrong choice for anything private, because there is no way to stop it spreading and no record of who opened it. If you would be uncomfortable finding it on a public page, do not use this setting.
- Set view rather than edit by default.Edit access lets the recipient change and delete the contents, and on some services move the file. Most sharing is so that someone can read something. Give edit access only when collaboration is the point, and remember that a shared folder with edit access is a place things can quietly disappear from.
- Use expiry and passwords where the service offers them.An expiry date converts a permanent exposure into a temporary one and is the single most useful setting most people never touch. A password on a link adds a second factor, provided it is sent by a different route — a link by email and a password by text is meaningfully better than both in the same message.
- Know what happens once someone has downloaded it.Revoking a link stops future access; it does nothing about a copy already downloaded. Some services can disable downloading for view-only recipients, which raises the effort without preventing a screenshot. Treat sharing as giving a copy unless you have specifically restricted it, and even then treat it as giving a copy to anyone determined.
- Review what you are already sharing.Every service has a page listing everything currently shared and with whom, and almost nobody has looked at it. Open it and work through the list: revoke what is finished, tighten anything set to anyone-with-the-link, and remove people who have moved on. Old shared links from years ago are still live until someone removes them.
- Handle sensitive documents differently.For identity documents, financial records and anything about a child, the sharing setting is not the whole answer. Password-protect the file itself so that possession of the link is not enough — the catalogue has a guide on that — send the password separately, and delete the file from the cloud once it has been received.
- Watch the folder-versus-file distinction.Sharing a folder shares everything in it, now and in future. A document dropped into that folder next month is shared too, without anyone deciding. Share individual files for one-off purposes and reserve shared folders for ongoing collaboration where you know what is in them.
- Check what the recipient actually sees before you rely on it.Open the link in a private browsing window, which is not signed in as you. If it opens, anyone with the address can open it. That thirty-second test is the most reliable way to know what you have actually shared, and it catches the mistakes that reading the settings does not.
Common mistakes
- Using anyone-with-the-link because it works first time — It works because there is no check. That is exactly what makes it unsuitable for anything private, and it is the default path of least resistance on every service.
- Assuming a long random link is secure — Unguessable is not the same as protected. Links get forwarded, pasted into group chats, stored in browser histories and occasionally published, and none of those require guessing anything.
- Sending a link and its password in the same message — It defeats the point. Anyone who sees the message has both. Send them by different routes — one by email, one by text.
- Sharing a whole folder to send one file — You have shared everything in it, including whatever is added later. Share the file.
- Never reviewing what is still shared — Shares do not expire on their own unless you set them to. A list built up over years is a list of live access you have forgotten granting.
If it doesn't work
The recipient says the link asks them to request access
Cause: It is restricted to named people and they are signed in as someone else — Fix: Check which address you shared with against the one they use, and ask them to check which account their browser is signed into. Being signed into a personal and a work account at once is the usual explanation.
The link works for everyone including people you did not send it to
Cause: It is set to anyone with the link — Fix: Change it to named people if the recipients have accounts, or accept it as public. There is no middle setting that keeps a link private once it has been forwarded.
You need to take back something already shared
Cause: The link is still live — Fix: Revoke the link or remove the person from the sharing list, which takes effect immediately for future access. Anything already downloaded is gone, so assess whether the content needs anything else doing — a changed password, a note to whoever it concerned.
A file you did not share is visible to someone
Cause: It is in a shared folder — Fix: Check the parent folders. Sharing is inherited downwards, and a file moved into a shared folder becomes shared with no separate prompt.
You cannot find where to revoke an old link
Cause: The shared list is not obvious — Fix: Each service has a shared-by-you view, usually in the sidebar, and each file's own sharing dialogue lists everyone who has access. The per-service name differs; the concept does not.
The recipient can edit when you meant them to read
Cause: The permission defaulted to edit — Fix: Change it in the sharing dialogue. Then check the version history, because if they have already changed something the earlier version is recoverable.
A shared link appears in a search engine
Cause: It was posted somewhere a crawler could reach — Fix: Revoke the link immediately and create a new one restricted to named people. Then use the search engine's removal request for outdated content — the catalogue's guide on removing personal information from search results covers the process.
Questions people ask
Is it safer to attach the file to an email instead?
Not particularly. An email attachment is a copy you cannot revoke, it sits in both mailboxes indefinitely, and it can be forwarded just as easily. A named-person share with view access is more controllable, which is why organisations increasingly prefer it. Attachments win only on simplicity and when the recipient has no account.
Can I see who has opened a shared link?
For named-people sharing, some services show who has accessed it. For anyone-with-the-link, generally not, because there is no identity to record. That absence of any record is itself a good reason to prefer named sharing for anything that matters.
What if the recipient has no cloud account at all?
Then anyone-with-the-link is your realistic option, so make it as narrow as possible: view only, an expiry date, a password sent separately, and revoke it once they confirm they have it.
Does this apply to shared photo albums?
Yes, and they are worth checking specifically. A shared album is an ongoing share of everything added to it, and album links are among the most forwarded things people create. The catalogue has a guide on sharing photo albums.
What about links generated by a file-transfer service?
Same reasoning. They are public addresses with an expiry, which is appropriate for large one-off transfers and not for sensitive material. Password-protect the file itself if the contents matter.