How to Deliver Large Files to Clients Without the Chaos
A calm, repeatable system for sending video, design source files, photo sets, and code archives that clients can actually open.
The Delivvo team· June 2, 2026 7 min read
The work is done. The edit is locked, the source files are organized, the export finished overnight. Then comes the part nobody warns you about: getting a four gigabyte folder into your client's hands without three days of back and forth.
Large file delivery is where polished projects go to look amateur. A bounced email, an expired link, a "request access" wall, a client downloading version two while you have already shipped version five. None of it is hard to avoid, but most freelancers improvise it every single time instead of building one system they trust.
This guide walks through why the obvious methods break, compares the real options on the dimensions that actually matter, and lands on a setup you can reuse on every engagement.
Why email attachments fail first
Email feels like the natural answer because it is where the rest of the conversation already lives. It is also the first thing to break.
Personal Gmail accounts cap attachments at 25 MB for what you send, according to Google's own support documentation. Outlook.com lands at the same place: Microsoft caps attachments at 25 MB and pushes anything larger to OneDrive instead. A single high resolution photo set, a one minute 4K clip, or a design file with embedded assets blows past that ceiling without trying.
There is a quieter problem too. The 25 MB figure is what the sender can attach. The receiving server may cap lower, and base64 encoding inflates an attachment by roughly a third on the wire. So a 20 MB file can arrive as a bounce on the client's end with no clear reason why. Email was built for messages, not for moving the actual deliverable.
Keep reading
Why the link services have a shelf life
The natural next step is a transfer link. WeTransfer made this normal, and for a long time it was the path of least resistance. The terms have tightened.
On the free WeTransfer plan, transfers are capped at 3 GB, links stay live for three days, and you get ten transfers in a rolling thirty day window. After acquisition the previous seven day window and looser caps were pulled back, and WeTransfer's current subscription terms reflect the new limits. Three days is the part that bites. A client who opens your email on Friday evening, forwards it to a colleague on Monday, and tries to download on Tuesday is staring at a dead link.
Smash is the usual alternative because the free plan has no hard size ceiling. The trade is time and patience: transfers over 2 GB sit in a queue, and Smash keeps free transfers available for seven days before they expire. Better than three, still a clock.
Expiry is not a bug in these tools. It is the business model. They are built for one-off sends, and they reset themselves so storage stays cheap. That is fine for a contractor you will never speak to again. It is the wrong foundation for a client relationship that runs for months and may need the same file re-pulled long after delivery.
A freelancer reviewing a large file transfer on a laptop screen
Why cloud drives trade one problem for another
Google Drive and Dropbox solve the size and expiry problem cleanly. Drive accepts individual files up to 5 TB per Google's documentation, and nothing expires on its own. So why does delivery still go sideways here?
Three reasons, and they all come from the same root: a drive is built for storage, not for handing something to an outsider.
The first is the access wall. Share a folder with the wrong permission setting and the client hits a "request access" screen. Now you are approving permission requests from your phone while they wait, and the smooth handoff you pictured turned into a support ticket.
The second is version confusion. You drop the final files into the shared folder, then realize the client already downloaded the previous cut. Or you update a file in place and they never notice, because nothing told them. Without an explicit "this is the deliverable, this is its status" signal, the client is guessing which version is real.
The third is professionalism. A naked Drive folder named "Client_Final_v3_REAL" with your personal account in the corner does not read like a studio. It reads like a file dump. For a one-time favor that is fine. For paid client work it quietly undercuts the rate you are charging.
The comparison that actually matters
Stop comparing these tools on size alone. Size is the easy axis. The dimensions that decide whether delivery feels professional are access friction, expiry, version clarity, and how the handoff looks to the client.
Email wins on familiarity and loses on everything else the moment a file is real. Transfer links win on speed and lose on permanence, because the link dies on a timer the client did not set. Cloud drives win on capacity and permanence and lose on friction, because they were never designed for a clean outside handoff. Each one is good at the thing it was built for and improvised at the thing you actually need.
What you actually need is narrow and specific. The client should click one link, see clearly labeled deliverables, know which version is current, download without an account or an access request, and still find the files there next month when their colleague asks. No timer, no permission dance, no guessing.
The system to standardize on
The fix is to separate two jobs that the consumer tools jam together: moving the bytes and presenting the deliverable.
For raw, enormous source files that a client only needs once, a transfer link is still the right call. Use it knowingly, tell the client the link expires, and move on. That is the correct tool for a 40 GB camera-original dump nobody will re-download.
For everything a client interacts with as a deliverable, the better pattern is a delivery space that belongs to the project rather than to a generic drive. A purpose-built client portal gives every project a single permanent link, presents files as labeled deliverables with a clear status instead of a folder of mystery names, removes the request-access wall because the link is the access, and carries your name instead of a stock cloud logo. The same place can hold the contract, the invoice, and the approval trail, so the file is not floating in isolation. We go deeper on this in client portal vs email for delivering freelance work.
One more piece keeps delivery calm: decide upfront what counts as final. If your scope says two rounds of revisions, the delivery space should make the current round obvious so a client cannot quietly treat a delivered file as an open invitation to keep editing. Tying delivery to a written revision policy that protects your time turns the handoff from a soft moment into a clear one.
Delivvo was built around exactly this gap. It gives each project a branded portal where deliverables live behind one stable link, clients download without an account, and the contract and invoice sit alongside the files, so the freelancer ceiling for uploads is generous enough for real video and source work rather than capped at a consumer tier. You can see how that fits together at Delivvo.
FAQ
What is the largest file I can email to a client?
Around 25 MB on personal Gmail and Outlook.com, and often less once the receiving server and encoding overhead are factored in. Anything above a few megabytes should not go as a raw attachment. Use a transfer link or a portal instead, and keep email for the note that points to them.
How long do WeTransfer links last?
On the current free plan, three days, alongside a 3 GB per-transfer cap and a ten-transfer monthly window. If a client downloads late or forwards the link to a colleague, it may already be dead. For files a client might need again later, a permanent link beats a timed one.
Is Google Drive or Dropbox good enough for client delivery?
They solve size and expiry but introduce access friction and version confusion. They were built for storage and collaboration, not for a clean outside handoff. They work if you manage permissions and labeling carefully every time. A portal removes that manual care because presenting the deliverable is its actual job.
Do I need a client portal if I only have a few clients?
The case for a portal is not volume, it is repeatability and the impression you leave. Even with two clients, a single permanent link with labeled, branded deliverables reads more like a studio than a transfer link that expires. The smaller your operation, the more the polish stands out.
