Upload-and-Link Services vs Peer-to-Peer: an Honest Comparison
Upload-and-link services, WeTransfer and its many relatives, are the most popular way to send a large file to someone, and for a good reason: they ask nothing of the recipient except clicking a link, whenever they get around to it. Peer-to-peer transfer asks for something they cannot always give: being online at the same time. ShareDrop.org is a P2P tool, so this comparison is written to be fair to the other side, because the other side wins some of these rounds.
How each one works
An upload service takes your file onto its servers, stores it for a period (commonly seven days on free tiers, longer when paid), and gives you a link. The recipient downloads from the service. The service is a temporary warehouse.
A peer-to-peer tool introduces two devices and then moves the file directly between them over an encrypted connection, with a relay forwarding encrypted packets when the networks cannot connect directly (how). Nothing is stored anywhere but the recipient's device. The service is a matchmaker, not a warehouse.
Head to head
| Upload-and-link | Peer-to-peer | |
|---|---|---|
| Recipient offline right now | Works: download later | Does not work |
| Several recipients | One link for all | One transfer each |
| Nothing to install, no account | Usually true for free tiers | True |
| Size limit | Free tiers: typically 2–5 GB per transfer | No protocol limit; receiver-dependent (details) |
| Copy stored by a third party | Yes, for the retention period, under their terms | No |
| Who can read the file | The service (unless it offers end-to-end encryption) and anyone with the link | Sender and recipient only |
| Total time, sender to recipient | Upload + download, sequentially | One pass; on the same Wi-Fi, no internet at all |
| Integrity check | Usually none visible | SHA-256 on arrival |
| Link exposure | Link works for anyone who obtains it until expiry | Short code expires in minutes; nothing to leak afterwards |
| Revoke after sending | Yes, if not yet downloaded | Not applicable |
Where upload services are simply better
Two situations, and they are common. First, the recipient is not available: a client in another time zone, a relative who checks email once a day, a colleague on holiday. P2P cannot help; a link waits patiently. Second, one file to many people: a press kit, a wedding album, a build for testers. A link scales for free; P2P is one session per person. In both cases the stored copy is not a bug, it is the feature you are using.
Where P2P is simply better
Also two. First, the file should not exist on anyone else's server — contracts, medical scans, source footage, anything under an NDA. With P2P there is no copy to subpoena, breach or forget to delete (what a service does still see). Second, the two devices are near each other: on the same Wi-Fi a P2P transfer never leaves the router and runs at LAN speed, while the upload service sends a 3 GB file out to the internet and back for two devices sitting on the same desk.
The speed question, honestly
Across the internet, both are bounded by the sender's upload speed. The upload service then adds the recipient's download; P2P delivers as it uploads, so the recipient has the file when the upload finishes rather than after a second wait. For a 5 GB file on a 30 Mbps upload, that is the difference between about 25 minutes and about 25 minutes plus however long the download takes. P2P via a relay keeps that property; the relay forwards in real time (measurements).
What about the security of the link?
A share link is a bearer credential: forwarding it forwards access. Services mitigate with expiry, passwords and download limits; use all three for anything sensitive, and send the password by another channel. P2P has no persistent credential (the short code pairs two devices for one session and is useless afterwards), but it has its own check to perform: compare the safety code on the two devices to rule out an intercepted introduction (why).
What the tiers typically buy
| Free tier (typical) | Paid tier (typical) | |
|---|---|---|
| Size per transfer | Low single-digit gigabytes | Hundreds of gigabytes |
| Retention | About a week | Weeks to months, or until deleted |
| Password on the link | Usually not | Yes |
| Expiry you control | Fixed | Yes |
| Who downloaded, and when | Sometimes | Yes |
| Ads shown to the recipient | Often | No |
Specifics vary by service and change often; the shape does not. The controls that make a link safe (password, expiry, tracking) are the ones behind the paywall, which is worth knowing before sending anything sensitive on a free plan.
Link hygiene, if you use one
- Set the shortest expiry the recipient can live with. A link that works for a week is a week of exposure.
- Add a password and send it by a different channel than the link.
- Use a download limit if the service offers one; a link meant for one person should stop working after one download.
- Delete the transfer from the service once the recipient confirms, rather than waiting for expiry.
- Never paste a link into a group chat or a shared document; anyone with it has the file.
For businesses: the audit trail
Here the upload service has a real advantage that peer-to-peer cannot match. A paid service records who downloaded which file and when, can brand the download page, and can enforce retention and access policies centrally. For an agency delivering work to clients, or a firm that must show a document was received, that record is the point. A direct transfer leaves no record anywhere; that is its privacy property and, in this context, its shortcoming. Choose by which you need.
Reading a service's privacy policy in three minutes
Five things to find, in order:
- Retention: how long after expiry the file actually exists, including backups.
- Scanning: whether files are scanned for malware or content, which means they are read.
- Encryption at rest and who holds the key: provider-held keys mean the provider can read the file (the distinction).
- Subprocessors: which other companies host or process the data.
- Deletion: whether “delete” is immediate, and whether you can request it.
If the policy does not answer these, assume the least private reading. A service that is proud of its privacy properties says so specifically.
Using both
The tools are not rivals in practice. Many people send the large or sensitive file directly while both are present and use a link for the small stuff, or start with a direct transfer and fall back to a link when the other person turns out to be away. The failure mode is treating one as the default for everything: links for files that should not be stored, or direct transfers to people who are not there.
Three real cases
- A designer delivering final files to a client. The client is in another time zone and the agency wants proof of delivery. An upload service on a paid plan: link with expiry, password sent by phone, download notification kept for the record.
- A family video to a sibling on a call right now. Both present, nothing to store, original quality wanted. Direct transfer; the safety code is a ten-second aside in the conversation.
- A press kit for forty journalists. Many recipients, no sensitivity, collected over a week. A link, and a service built for distribution rather than a personal drive, which may throttle a popular file.
When a link expires
On expiry the service deletes the file under its retention policy and the link returns an error; some keep the transfer's metadata (who sent what to whom, when), for longer, for their own records. A recipient who missed the window needs a new upload, which is the one recurring cost of the model: the sender does the work again. Set an expiry long enough for the recipient's habits and short enough for your comfort, and ask for a quick “got it” so you can delete early rather than wait.
Verdict
- Recipient unavailable, or many recipients: upload-and-link. No contest.
- Sensitive file, or both devices nearby, or both people present: peer-to-peer. No contest.
- Everything else: either; choose by whether you want a copy to exist afterwards.
Keep both in your toolkit. The mistake is not picking the wrong one occasionally; it is using the same one for everything.
