Cloud storage or a transfer link? They are built for different verbs
Drive, Dropbox and OneDrive all produce a share link, so why use anything else? Because storage is for files you keep and transfer is for files you hand over — and one question tells you which you have.
Google Drive, Dropbox and OneDrive can all produce a share link, so it is reasonable to ask why anyone would use something else. The answer is that they are built for a different verb.
Cloud storage is for files you keep. Transfer is for files you hand over. Most of the friction people feel comes from using one for the other's job.
If you already know which verb you want and just need to pick a service, the comparison table puts the drives and the transfer tools next to each other on the same measurements.
The difference in one line
A cloud folder is a place your file lives, and sharing is a permission granted on it. A transfer is an event with an end date, and the link is the whole of it.
That single distinction produces every difference below.
Where cloud storage is the right answer
- Ongoing collaboration. Several people editing the same document over weeks. Version history, comments and simultaneous editing are the entire point, and no transfer tool replaces them.
- A shared workspace that outlives any one exchange — a team drive, a client folder for a year-long engagement.
- Your own backup and sync. Different job again, and the one it does best.
- Files you will refer back to. If you need it again in six months, it should live somewhere, and a transfer that expires is the wrong home.
Where it goes wrong as a delivery mechanism
Access does not end. This is the big one. A link set to "anyone with the link" stays live until somebody remembers to revoke it. Nobody remembers. Every project leaves behind live links, and after a few years an organisation has thousands of shares nobody can account for.
A transfer with an expiry inverts the default: access ends unless you deliberately extend it, and the cleanup happens whether or not anybody is paying attention.
Sharing outside the organisation is awkward. Corporate tenants routinely restrict external sharing, so the client gets a request-access screen. Then somebody approves it, or emails the file instead, and the control was theatre.
The permission model is easy to get wrong. "Anyone with the link can edit" is one dropdown away from "anyone with the link can view", and the failure is silent. Worse, sharing a file from inside a shared folder sometimes shares more than intended.
It counts against your storage. Sending a 30 GB video means keeping 30 GB, for as long as the link needs to work.
The provider can read the contents. Preview, search and thumbnails all require it. That is a reasonable trade for a working folder; it is a different question for a one-off transfer of something sensitive. See what end-to-end encryption actually means.
Side by side
| Cloud storage | Transfer link | |
|---|---|---|
| Built for | Keeping and collaborating | Handing over once |
| Access ends | When someone revokes it | On the date you chose |
| External recipients | Often need an account | Click and download |
| Counts against quota | For as long as it exists | Until it expires |
| Provider can read it | Yes, by design | Not if end-to-end encrypted |
| Editing together | Yes | No, and not trying to |
| Audit of one hand-off | Buried in activity logs | Download count per transfer |
The test
Ask one question about the file: will anyone need to open this in six months?
If yes, it belongs somewhere it lives — a drive, a repository, a workspace. If no, it is a hand-off, and it should have an end date attached from the moment you send it.
A second question catches most of the rest: is anyone going to change it? Files that will be edited want a folder. Files that are finished want a link.
Using both, sensibly
Most people should. Keep the working files in whatever your team already uses; deliver the finished ones with an expiring link. That way the archive stays complete and the deliveries clean up after themselves.
If you take one habit from this: when you next create an "anyone with the link" share for a one-off hand-off, notice that you have just published a file with no end date, and decide whether you meant to.
Related: choosing a file transfer service, how long a download link should last, and SFTP or a transfer link.
