Sending a file attaches a frozen copy to an inbox; sending a link hands over a URL you still control. The three places that gap shows up — size ceilings, what actually renders, and who holds the deliverable after it lands.
You finish the thing. Now you have to get it to someone. The default reflex is to attach it — drag the file into the email, type a line, send. It feels like handing the work over. It mostly isn't. What you handed over is a copy, and the copy and the original quietly go their separate ways the instant you click send.
A link does something different. It doesn't move the file into their inbox. It hands them an address where the file lives, and you keep holding that address. Same content, opposite mechanics. The difference only matters in three places — but those three decide most deliverables, so it's worth being deliberate about which one you reach for. This isn't an attachment-versus-link morality tale; it's a question of matching the container to the cargo.
Email was built to carry messages, not payloads. Most providers cap a single message somewhere around 20–25 MB, and here's the part that bites: the receiving server gets a vote too, and it can be stricter than yours. A file that sails out of your outbox can still bounce on the other end, and you find out hours later — or never.
When the file is too big, one of two unhappy things happens. Either the provider quietly reroutes it to a cloud drive and bolts on its own sharing prompts — so now your "attachment" is secretly a link anyway, just one you didn't design. Or it's rejected, and you're back in your outbox repackaging.
A link removes the ceiling because the email never carries the weight. It carries a URL. A 40 MB interactive report and a one-line "here's the deck" travel as the same featherweight message. We wrote a whole piece on the bounce itself — sending a 50 MB HTML file when email refuses is a real and common dead end — and the fix is always the same shape: stop shipping the payload, ship the address.
This is the one people forget until it embarrasses them. A PDF is forgiving as an attachment because mail clients preview PDFs natively. A spreadsheet survives because the recipient has the app. But a web deliverable — a self-contained HTML page, an interactive dashboard, a slide deck built to run in a browser — does not.
Sent as an attachment, an HTML file usually lands as raw .html. Best case, it downloads and the recipient double-clicks it open from their Downloads folder, detached from any context. Common case, the mail provider strips or sandboxes it for security, because an executable web page arriving in an inbox is exactly what providers are trained to distrust. The charts that were interactive go inert. The thing you built to run arrives as a file to open.
Hosted at a link, the same page runs the way you built it. The recipient clicks, it opens in the tab next to whatever they were already doing, the scripts execute, the layout holds. Nothing to download, nothing to trust-prompt, nothing to explain. This is the whole reason HTML hosting exists as a category — a web page wants to be visited, not attached.
This is the quiet one, and it's the one that compounds.
An attachment detaches. The moment it's in their inbox, it's a copy you no longer touch. You can't revise it — you can only send a "use this one instead" follow-up and hope the first one dies. You can't expire it. You can't tell whether it was opened. And every forward spawns another copy, so the version you sent in March is still circulating in someone's thread in June, looking exactly as authoritative as the corrected one.
A link keeps one source, and you keep your hand on it:
None of that is possible once a file is sitting in someone's inbox. It's a copy. It answers to no one. The link is still yours.
A link isn't universally better, and pretending so would be selling. Send the file as an attachment when the file is supposed to detach — when offline-durable is the feature, not the bug.
A signed contract belongs in the inbox as a PDF; e-signature workflows are PDF-native and the frozen copy is the legal artifact. A CSV someone will import into their own system wants to be a file, not a page. An invoice they'll need in seven years for an audit should outlive any URL you control. Anything where the recipient's correct action is "save this and keep it forever, independent of you" is an attachment job. The link's whole value — that you still hold it — becomes a liability when the point is that they should hold it instead.
And the deeper boundary: a link is only as good as what's hosting it. If your deliverable needs a live server, a database, logins, or anything that computes per-visitor, that's a backend job — reach for Vercel or Netlify and give it a real runtime. A static-link host (miinideck included) is the right tool only for the static slice: a self-contained page, a ZIP that runs in the browser, a deck, a report, a dashboard whose data is baked in. Match the container to the cargo.
Picture the recipient's first move. If the right thing for them to do is save this file and keep it, on their own, forever — attach it. If the right thing is open this and look at it, while you keep the ability to update or pull it — send a link.
Most deliverables in 2026 are the second kind. They're meant to be read, clicked through, reacted to — not filed. They get revised. They have an audience that might change. They're web-shaped. For all of those, the attachment quietly works against you the moment it lands, and the link keeps working for you. That's the case for sending a file as a link rather than an attachment: you're not just shrinking the email, you're keeping the deliverable yours.
If your deliverable is a self-contained web page or a ZIP of one, miinideck is the one-step version of the link side: drop it, get a private, unguessable URL, paste it into the email. The file stays out of the inbox. The deliverable stays yours.
Sending a client a finished page? A Drive link hands them a file in a filing cabinet to download or preview flattened. A private link hands them the thing itself, already open. The three places the two diverge: rendering, control, and who the link assumes the reader is.
WeTransfer is a courier: it drops the file and leaves, and the link self-destructs. A private link is a room that stays open. Which fits depends on whether you're moving a file or showing a finished page — and on how big it is.
A ZIP is a moving box: the recipient has to unpack it, find the entry file, and hope their mail provider didn't strip it. A hosted link is the room already set up. When a multi-file build should travel as a link instead of an attachment.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.