How to Send Large Files to Non-Technical Clients

The easiest transfer is the one where the client clicks a link, previews or downloads the file, and never has to create an account. Optimize the recipient experience first, then add security and retention controls around it. Starting with the most powerful transfer system instead of the simplest recipient path creates support work for you. A good default rule:

Email is for tiny previews only.
A browser-based transfer link handles one-off delivery.
A client portal or managed file transfer workflow fits files that are large, sensitive, recurring, or tied to approval.
Physical media or a cloud ingest location is for when the client’s network can't handle the transfer at all.

That sounds simple, but the details matter. A 200 MB PDF deck and a 12 GB ProRes export fail in different ways. So do a 90 GB camera card and a folder of mixed audio stems.

Start with the client’s actual constraint

Before choosing the tool, identify what will break on the client side. Non-technical clients are often on a locked-down corporate laptop or hotel Wi-Fi. Others are cutting it close to a newsroom deadline, or sitting behind a company network with strict download rules. The common constraints are one of these:

They can't receive email attachments over a small limit, often around 25 MB.
They can't install desktop apps, browser extensions, FTP clients, or sync tools.
Their IT department blocks unfamiliar file-sharing domains.
Their network is too slow or unstable for a single huge file.
They need to preview the file before committing to a download.

So “send me the file” isn't enough detail. Ask one practical question: “Can you download a file from a browser link, or does your company block large downloads?” That answer determines whether you send a normal link or split the delivery. It also tells you whether to provide a proxy, involve IT, or ship a drive.

Use the smallest delivery that satisfies the job

Large file delivery gets easier when you separate review from final delivery. Many client problems happen because teams send massive masters when the client only needs to approve content. For review, send a lightweight viewing file whenever possible. An H.264 or H.265 MP4 with a clear filename is easier for a client to open than a mezzanine export or an EXR sequence. The same goes for a WAV stem package or a camera original folder. If the client only needs to comment, approve, or choose a take, don't make them download 80 GB. For final delivery, preserve the requested quality. If the spec calls for ProRes, DNxHR, or WAV, deliver exactly that. The same holds for TIFF, layered PSD, and camera originals. Don't run everything through a consumer compression tool just to make transfer easier. Use a transfer method that can handle the original files without re-encoding or quality loss. A practical delivery pattern looks like this:

Send a small MP4, PDF, JPEG set, or audio preview for review.
Include a short email explaining what the client should open first for approval context.
Deliver the final asset as an original-quality file or folder package.
Add a delivery note with the file count, expected size, expiration date, and who to contact if access fails.

This gives the client a low-friction path while still protecting the production deliverable.

Browser-based transfer links are the default for one-off delivery

For most non-technical clients, a browser-based transfer service is the cleanest option. The sender uploads files, the service generates a link or email notification, and the recipient downloads through a web page. The client doesn't install anything, doesn't configure FTP, and ideally doesn't create an account.

Keep the client’s path as simple as possible: a browser link, not an installation process.

This category works well for:

Final exports
Small batches of stills
Audio mixes and stems
Review PDFs
Design packages

The services differ mostly on one axis: how big a package they will carry, and what that costs.

Service	Free tier	Paid entry	Per-transfer ceiling
WeTransfer	3 GB per transfer, but capped at 3 GB total across 10 transfers per rolling 30 days, expiring in up to 3 days	Starter $10/month	300 GB on Starter; no stated limit on Ultimate at $25/month
Dropbox Transfer	2 GB per send	Bundled with paid Dropbox plans	Up to 250 GB on higher plans or with add-ons
Smash	No size limit, files held 7 days	Pro, published pricing	250 GB on Pro, up to 1 TB on Team
Filemail	5 GB per transfer, 2 transfers per day	Pro $20/month	250 GB on Pro; unlimited on Business and Enterprise
MASV	15 GB per month	$250 per TB, no subscription required	No practical ceiling; billed by volume
Signiant Media Shuttle	None	Not published; annual subscription by user tier	Built for sustained multi-terabyte movement

The WeTransfer free tier is the one most people misremember. It was 2 GB per transfer for years, and it is now 3 GB — but the 3 GB is a monthly total across a maximum of ten transfers, not a per-send allowance you can use repeatedly. A studio sending three 2 GB exports in a week will hit the wall partway through the second one. The other pattern worth knowing is that the sender and the recipient have different requirements. MASV and Signiant expect the sender to install something or work in a managed portal, while the recipient just clicks a link. That is the right trade for heavy media. Smash and WeTransfer keep both ends in a browser, which is the right trade when the file is small enough not to need acceleration. The sender may still benefit from a desktop app for very large or unstable transfers, but the recipient shouldn't need one. That distinction is the whole point. It's fine if your post team uses an app to upload a 400 GB package more reliably. It isn't fine if the client has to install that app just to download a final cut.

When cloud drive links work, and when they create friction

General cloud storage is familiar, which is its biggest advantage. Many clients already know how to open a shared folder from common office ecosystems. If the client’s company standardizes on one platform, using that platform may be easier than introducing a new transfer service. Cloud drive links work best when:

The client already has access to the platform.
The files need to stay available for weeks or months.
Multiple people need ongoing access.
You're sharing organized folders rather than a one-time package.
The client may need to come back later for the same assets.

They cause friction when permissions get too clever. The classic failure is sending a link that works for you, but not for the client. The next most common failure is requiring the client to sign into the wrong account. After that comes version confusion, where the client finds an old file in a shared folder and comments on the wrong export. If you use a cloud drive, keep the structure predictable. Create a client-facing delivery folder rather than a maze of internal project directories. Don't expose working files unless the client needs them. Name the current delivery clearly, and move superseded versions into an archive folder if they must remain visible.

Avoid FTP for non-technical client delivery

FTP still appears in media workflows, especially around broadcast, archive, and older vendor handoffs. For non-technical clients, it's a poor fit. Traditional FTP has several problems for this use case:

It often requires separate client software.
Firewalls can block or complicate it.
Basic FTP doesn't encrypt credentials or transfers.
Folder navigation can be confusing for recipients.
The client may not notice failed transfers.

Secure variants and managed systems can solve some of this. At that point you're better off giving the client a browser portal or managed link. Keep FTP-like workflows for technical partners who already know the process and have a tested endpoint.

Package files so the client knows what they received

The link gets the client to the download page, and the package tells them whether they downloaded the right thing.

A clear package helps the client recognize what they downloaded.

For a single export, keep the filename readable and specific. Include project, version, date, and purpose. Avoid internal shorthand that only your team understands. For multi-file deliveries, preserve folder structure when the transfer tool supports it. If the service doesn't handle folders well, create a compressed archive, but be careful with huge ZIP files. A single 150 GB archive can be painful for a client on a flaky connection, because one failed download can mean starting over. For very large deliveries, separate the package into logical folders or volumes. Useful package details include:

Project or campaign name
Version number or delivery date
Asset type, such as review, final, audio, stills, subtitles, or source
File count
Total package size
Any required software or codec note
The person responsible for the delivery

These details reduce “I downloaded something but I’m not sure what it is” emails.

Manage expiration dates like a production detail

Expiring links are useful because they limit exposure, reduce stale access, and keep temporary delivery services from becoming unmanaged archives. They also create a predictable support problem: the client misses the window and asks you to resend. Set expiration based on real client behavior rather than the default. A seven-day link may be fine for a producer on deadline. It may be a bad fit for a corporate client who needs legal, brand, and regional teams to review before downloading. A practical expiration policy can be simple:

Use 3 to 7 days for same-day deadline delivery.
Use 14 to 30 days for normal client review or download.
Use 30 days or a persistent client folder for a multi-department handoff.
For sensitive unreleased material, use the shortest window that still fits the business need.
For final archive delivery, don't rely on an expiring transfer link as the archive.

Tell the client the expiration date in plain language. “This download link expires Friday at 5 PM Eastern” is better than assuming they'll notice the transfer page. If the asset is important, send a reminder before expiration or use a service that shows whether the client downloaded it.

Expiration should be an obvious delivery detail, not a hidden setting.

The important distinction is transfer versus storage. A transfer link is for moving files. It isn't your archive, your delivery record, or your only copy.

Balance security with accessibility

Security controls are only useful if the client can get through them. For non-technical recipients, every added step increases the chance of a support email. The trick is to match controls to risk. For low-risk files, a private link sent directly to the client may be enough. For unreleased media, legal documents, or financial data, add more control. Talent materials and confidential campaign work need the same treatment. Common controls include:

Password-protected links
Email-restricted access
Link expiration
Download limits
Watermarked preview files
Download notifications
Malware scanning
Checksum verification
MFA or SSO for higher-security portals

If the material is sensitive, don't send the password in the same message as the link. Use a separate channel, such as text, phone, or a separate email thread. If the client’s team will forward the link internally, email-restricted access may become frustrating unless you know every recipient in advance. In that case, a password plus expiration may be more practical. For high-security media workflows, use a managed transfer service or approved client portal. Look for audit logs, encryption in transit and at rest, and access reporting. For casual delivery, don't overbuild the process. Don't force a CEO who just needs to download a board presentation through a production-grade portal unless the content demands it.

Verify the file before and after transfer

For original camera data and high-value production media, basic file copy isn't enough. Professional media workflows use checksum verification to confirm that files copied completely and without corruption. This is especially important before erasing camera cards, shuttle drives, or temporary storage. In practical terms, your team should verify in two places. First, verify your source package before uploading. If you're sending camera originals, exports, or a folder that came from a DIT, confirm that the package is complete and that any checksum manifest or media hash list matches. Don't upload a folder you haven't checked, then make the transfer tool responsible for proving your source was good. Second, use transfer tools that provide integrity checks, resumable transfers, or download confirmation when the stakes justify it. A simple link may be fine for a 300 MB approval MP4. A 2 TB production handoff needs more evidence. Mention the expected file count and size in your delivery note. That gives the client or receiving technician a simple way to spot obvious problems before they start using the media.

Help clients who can't download huge files

Sometimes the client is willing but their environment isn't. Their company blocks large downloads, or their office Wi-Fi drops every hour. Their browser may choke on a massive package, or their IT team may quarantine unknown archives. In those cases, changing tools may not be enough. There are a few workable approaches:

Send a smaller proxy for review and delay full-resolution delivery until IT approves a path.
Split the delivery into smaller logical packages, such as reels, days, scenes, or asset types.
Use a managed transfer service with resumable downloads.
Upload directly into the client’s approved bucket, workspace, or MAM when available.
Ship an encrypted physical drive for very large datasets or locked-down environments.

Splitting files often saves the day. A client who can't download one 120 GB archive may successfully download twelve 10 GB packages. Just avoid arbitrary chunks with unclear names. Split by meaning whenever possible.

When one huge download fails, smaller packages may get through.

For very large media, physical delivery is still valid. It's slower than a good network transfer, but faster than a failed upload repeated three times. If you ship drives, encrypt them, track them, and send the password separately.

Write the email like the client has never used the tool

The delivery message is part of the workflow. Keep it short, specific, and free of technical jargon. A good client delivery note includes:

What the file is
What they should do with it
Whether they can preview it in the browser
Whether they need to download it
The total size
The expiration date
The password process, if applicable
Who to contact if the link fails

For example: “Here is the final 4K master for the launch film. You can open the link in your browser and download the file without creating an account. The download is 18.6 GB, so please use a stable connection. The link expires on Friday at 5 PM Eastern. I’ll send the password separately.” That message prevents most confusion. It also sets expectations around file size, timing, and access.

Choose based on the handoff pattern

The right solution depends less on the file size alone and more on how often this handoff happens.

Handoff pattern	Better delivery choice	Useful controls	Why it helps the client
One-time file delivery	WeTransfer, Smash, or MASV, none of which need a recipient login	Expiration, optional password, download notification	The client can open one link and download without installing anything
Recurring client delivery	A branded portal such as Signiant Media Shuttle, or a dedicated client folder in Dropbox or Aspect	Permissions, version naming, access history	The client always knows where current deliveries live
Review and approval	Lightweight MP4, PDF, still set, or review link	Watermarking, comments, link expiration	The client can approve content without downloading full-resolution media
Sensitive unreleased media	Managed transfer service or approved client portal	Encryption, access restrictions, audit logs, download tracking	Security is stronger while the recipient path stays controlled
Client has download limits	Smaller logical packages, resumable transfer, or upload to their approved system	Clear file counts, package sizes, retry support	Failed downloads are easier to recover from
Very large source or camera media	MASV or Signiant for resumable managed transfer, or an encrypted physical drive	Checksums, drive tracking, separate password channel	The delivery preserves integrity and avoids repeated failed transfers

For a one-time delivery to a non-technical client, use a browser-based transfer link with no recipient login. Add a password and expiration if needed. For recurring client delivery, use a dedicated client folder, branded portal, or managed transfer workspace. Keep naming and folder structure consistent so the client always knows where current files live. For review and approval, don't send full-resolution files unless the client requires them. Send a preview file or review link, then deliver masters after approval. For sensitive unreleased media, use a managed service with access controls, expiration, encryption, and download tracking. Keep the client path simple, but don't rely on public-style links for confidential assets. For clients with download limits, split the packages or use resumable transfer. Delivering into their approved system works too, and encrypted physical media is the fallback. The best workflow lets the client receive the file without calling you, while your team keeps enough control to protect the asset and prove delivery. If you change one habit, make it this: ask the browser-link question before you upload anything.

FAQ

Use a browser-based transfer link that lets the client preview or download the file without installing software or creating an account. For most one-off deliveries, this is easier than FTP, sync apps, or shared workspaces. Add an expiration date, password, or download notification if the file needs more control.

Send the smallest file that satisfies the client’s immediate need. If they only need to review, comment, or approve content, send a lightweight MP4, PDF, JPEG set, or audio preview. Save the production-quality files for final delivery or for when the spec requires them: ProRes, DNxHR, WAV, TIFF, and camera originals.

Set the expiration based on how the client will actually use the file. A deadline delivery may only need 3 to 7 days, while normal review may need 14 to 30 days. Multi-department reviews may need a longer window or a persistent client folder. Always state the expiration date clearly in the delivery email.

First confirm whether their company blocks large downloads or whether the issue is connection stability. Then consider sending a smaller proxy, splitting the delivery into logical packages, or using a resumable transfer service. Uploading into the client’s approved storage system works too, and an encrypted physical drive is the fallback. For very large media, a tracked physical drive can be more reliable than repeated failed downloads.

Tell the client what the file is and what they should do with it. Say whether they can preview it in the browser or have to download it. Include the total size, the expiration date, and who to contact if access fails. If the link is password-protected, send the password separately when the material is sensitive.

Use a managed share instead of a public-style link when the asset is sensitive or likely to be forwarded. Aspect lets teams set view or download access, plus password protection and expiry, as part of granular sharing permissions.