“How do I send this file” has four reasonable answers, and most frustration comes from using one method for a job that wanted another.
This compares them. If your question is specifically about doing it without paying, that has its own guide.
First, why email is not on the list
Attachments are encoded into the message body, which inflates them by about a third, and every server on the route holds the whole thing. Gmail stops at 25 MB, Outlook at 20 MB, corporate servers frequently lower.
The size cap is not even the main problem. An attachment is copied permanently into every recipient’s mailbox and your sent folder. It cannot be corrected, revoked or expired. Send a 20 MB file to eight people and you have created 160 MB of storage that nobody will ever clean up, containing a version of the file that may be wrong by Thursday.
Our guide to Gmail’s limit covers the workarounds if you are stuck with email.
Method 1: a share link
Upload once, send a URL. The recipient downloads directly and needs no account.
Best for: sending finished work to someone outside your organisation. Client deliverables, portfolio pieces, anything where the recipient’s technical setup is unknown and must not matter.
What makes it good: one copy exists, so you can replace the file without sending a second email. You can revoke access when the project ends. You can see whether it was actually downloaded, which ends a whole genre of follow-up messages.
The controls that matter. A raw link works for anyone who has it, which is right for a portfolio and wrong for a contract. Set an expiry date so access ends on a date you chose rather than continuing forever by default. Add a password when forwarding is the concern, or restrict to named email addresses when the material is sensitive - our guide to sensitive documents covers choosing between them.
Where it falls down: repetition. If you are sending a link to the same person every week, you are doing manual work a mounted drive would eliminate.
Method 2: a direct transfer
Two devices on the same network move the file between themselves. Nothing is stored in the middle.
Best for: a one-off handoff to someone physically nearby, especially a large file that nobody needs again. Handing footage to an editor sitting across the room.
What makes it good: it is the fastest option by a wide margin, because local network speeds beat almost any internet connection, and there is no upload step at all. Nothing is retained afterwards, which is occasionally the entire point.
Where it falls down: both parties must be present and on the same network at the same time. There is no record, no second chance, and no way to re-download it next month.
Method 3: a mounted drive
The remote storage appears as a folder in Finder or Explorer. You save into it and the “transfer” step stops existing.
Best for: ongoing collaboration. The same people needing the same files, week after week.
What makes it good: it removes the decision entirely. Nobody sends anything; the file is simply where both parties look. Version confusion drops sharply because there is one copy rather than a chain of emailed attachments.
How to set it up: natively on macOS and Windows over WebDAV, which needs no extra software. If a script rather than a person is the client, the S3 API is the better protocol - our comparison explains where the line falls.
Where it falls down: a network drive is not a local disk. Browsing folders with thousands of files is slow, and applications that write constantly in small increments feel worse than those that save whole files.
Method 4: a file request
Turn the direction around. Instead of sending a file, you send a page that someone uploads to.
Best for: collecting. Client assets, contributor submissions, documents from someone who is not technical.
What makes it good: the person uploading needs no account, no software and no instructions. It also arrives organised in one place, instead of scattered across an email thread where you find yourself asking whether v3 was the latest.
Where it falls down: it is the wrong shape for sending. If you are the one with the file, this is not your method.
Choosing quickly
| Situation | Method |
|---|---|
| One-off to an external client | Share link with an expiry |
| Sensitive contract or personal data | Link restricted to named emails |
| Large file, recipient in the room | Direct transfer |
| Same files, same people, every week | Mounted drive |
| You need files from someone | File request |
| A script or backup job is the client | S3 API, not a link |
The mistake worth avoiding
Almost every complaint about file sharing traces back to one thing: using share links for a workflow that repeats.
Links are excellent for delivering something finished to someone outside your world. They are tedious for the ninth transfer of the same working file to the same colleague. When you notice you are repeating yourself, that is the signal to mount the storage and stop sending anything at all.
