Attachments or links? What the paperclip actually costs
An attachment is not sent to a recipient, it is copied to every one of them and stored forever in mailboxes you do not control. When that is still the right call, and when it plainly is not.
Attaching a file is the default because it has been the default since before most of us had email. It is worth knowing what it actually costs, because for anything above a few megabytes the alternative is better on almost every axis — including some that have nothing to do with size.
What an attachment really does
An attachment is not sent to a recipient. It is copied to every recipient, encoded as text along the way, and stored indefinitely in every mailbox it touches.
Send a 10 MB deck to eight people and you have created eight copies plus your own, permanently, in nine mailboxes you do not control. Reply-all a few times and it multiplies again — most people have received the same attachment three times in one thread.
The encoding matters too: attachments are inflated by about a third on the way out, which is why a 20 MB file fails a 25 MB limit. The details are in email attachment size limits.
What a link does instead
One copy, in one place, with an end date. The message carries a few dozen characters. Eight recipients means eight people fetching the same object, not eight copies of it existing forever.
And because the file is not the message, you keep some control after sending: you can see whether it was downloaded, and you can revoke it. Neither is possible once an attachment has left.
Side by side
| Attachment | Link | |
|---|---|---|
| Size ceiling | ~18 MB of real file | Whatever the service allows |
| Copies created | One per recipient, forever | One, until it expires |
| Take it back | Impossible | Revoke, immediately |
| Know it arrived | No | Download count |
| Sending a new version | A second attachment, and confusion | A second transfer, clearly dated |
| Survives corporate filters | Often stripped | Usually fine |
| Works offline later | Yes, it is in the mailbox | No, once expired |
When an attachment is still right
This is not a one-sided argument. Attach it when:
- It is small and permanent. A signed PDF that should live in the recipient's records, at 200 KB, belongs in the mailbox. Making that expire would be actively unhelpful.
- The recipient's process requires it. Plenty of systems ingest attachments automatically. Do not fight the pipeline.
- It needs to be readable in ten years. A link is a dependency on a service still existing; a file in an archived mailbox is not.
- The recipient is not technical and the file is tiny. An attachment is one fewer step.
The distinction is roughly record versus delivery. A record wants to persist in their possession. A delivery wants to arrive and then stop existing.
When a link is clearly right
- Anything over about 15 MB, where an attachment may simply not arrive.
- Anything going to more than two or three people.
- Anything you might need to withdraw or replace.
- Anything sensitive, where a permanent copy in several mailboxes is the risk. An encrypted transfer that expires is a much smaller footprint than a plaintext attachment sitting in inboxes indefinitely.
- Anything where knowing it was received matters.
The habit worth changing
Most people reach for the paperclip and only switch to a link when the attachment is rejected. Inverting that — link by default, attach when the file is small and belongs in the record — costs nothing and quietly fixes the version confusion, the four copies in one thread, and the file you wish you had not sent.
One caveat when you do send links: a message containing only a URL looks like phishing to both filters and people. Two lines of context solve it. See when the link email goes to spam.
Related: email attachment size limits, cloud storage vs transfer links, and how to send large files.
