What's the Best Way to Send a Large Video File to a Client?

The best way to send a large video file to a client is to upload it to a spatial data delivery platform that preserves the original file untouched and plays it directly in the client’s browser, then share a branded link. The client streams the exact footage you exported — full resolution, no quality loss — without downloading gigabytes or finding a player.

That is the short answer, and it is the answer most people get wrong. Almost every “easy” way to send a video silently re-compresses it. I have spent eight years moving large spatial files around, and video is the format where the hidden quality loss bites hardest — because it does not look like an error. The file arrives. It plays. It just is not the video you exported.

The hidden trap: most methods re-compress your video

Here is the thing nobody tells you. When you send a video through email, iMessage, WhatsApp, or YouTube, the service does not move your file from A to B. It transcodes it — re-encodes the footage into its own format, at its own bitrate, with its own compression settings. Your carefully colour-graded, full-bitrate export gets quietly rebuilt into something smaller and softer.

For a holiday clip, who cares. For a client deliverable — a drone flythrough, an inspection walkthrough, a marketing render you charged for — it matters enormously. The client is judging your work by a degraded copy you never approved.

So the real question is not “how do I get this file to the client?” It is “how do I get the client the file I made, not a re-compressed imitation of it?”

Comparison: how each method handles a large video

Here is every common method, by maximum size, whether it re-compresses, and whether the client can actually watch it in the browser.

Read that “re-compresses” column carefully. Three of the five mainstream options destroy quality before the client ever sees the video. The two that preserve the original — cloud storage and a delivery platform — split on the experience: cloud storage forces a download and a hunt for a player; a delivery platform streams the original in the browser.

Where each method actually fails

Email — the non-starter

Gmail caps attachments at 25 MB. Outlook at 20 MB. A single minute of 1080p footage is comfortably 100+ MB; 4K is several hundred. Email is out before you start, and the inline previews some clients generate are re-compressed anyway. Mentioned only because people still try.

iMessage and WhatsApp — the silent quality-killers

This is the trap most people fall into. You drag a video into WhatsApp, it sends, the client watches it. Easy. Except WhatsApp re-encodes video down to roughly 720p at a low bitrate, and older clients cap attachments at 16 MB. iMessage does the same — it transcodes to keep messages small, and “Send as Low Quality” is not even the worst of it.

Your client is not watching your 4K export. They are watching a heavily compressed phone-grade copy. For a survey flythrough or an inspection clip where detail is the whole point, this is unacceptable — and the client has no idea it happened.

Google Drive and Dropbox — preserved, but no playback

Credit where due: Drive and Dropbox store the original. The bytes you upload are the bytes that come down. No re-compression.

But the client experience stops at a download button. They click the link, download a 5 GB file, wait, then need a video player that handles your codec and container. Drive’s own in-browser preview does transcode for streaming — so if they “preview” it there, they are back to watching a re-encoded version. To see the real quality they have to download the whole thing and open it locally. The file has been transferred. The video has not been delivered. There is a difference, and it is the whole point.

YouTube / Vimeo unlisted — convenient, wrong tool

Unlisted YouTube feels clever: a link, instant streaming, works on any device. But YouTube re-encodes everything into its own streaming formats. Your master is gone the moment it finishes processing — what the client streams is YouTube’s compression, not yours.

You also surrender control. Ads adjacent to your brand, “watch next” suggestions pulling the client away, no audit trail, no branding, and a deliverable living on a consumer platform you do not own. Fine for a public showreel. Wrong for a paid client deliverable.

Want the deeper, step-by-step workflow? Read our full guide to sending large video files to clients — codecs, bitrates, upload reliability, and delivery in detail.

The standard that actually solves it: preserve + stream

The two things a client deliverable needs are simple, and almost nothing does both:

1. Preserve the original. The file the client sees is the exact file you exported — same resolution, same bitrate, same colour. No transcoding pass anywhere in the chain.
2. Stream it in the browser. The client clicks a link and watches immediately, on any device, without a multi-gigabyte download and without finding a player that understands your codec.

Messaging apps and YouTube give you the playback but destroy the original. Cloud storage preserves the original but kills the playback. A delivery platform is the only category built to do both at once.

What delivery looks like

When you deliver a large video properly, the client:

1. Clicks a branded link in their browser
2. Sees the video stream immediately, at the quality you exported
3. Scrubs, pauses, and replays — no download required to watch
4. Can still download the original master if they need it for their own edit
5. Does all of this without installing anything

The original is preserved and streamable. Compare that to a 5 GB file sitting in a Downloads folder, or a 720p WhatsApp copy, and the gap is obvious.

Sending a 5 GB video specifically

A 5 GB export is a normal drone or inspection deliverable — and the size where the easy methods collapse. Email cannot touch it. iMessage and WhatsApp will compress it into something far smaller and visibly worse. Drive and Dropbox will move it, but as a 5 GB download the client must wait on.

Two things matter at this size:

• Upload reliability. A 5 GB single-request upload fails entirely if your connection blips. Use a platform with multipart upload that splits the file into chunks and resumes after an interruption, so you do not restart a 20-minute upload from zero.
• Streamed playback. The client should not have to download 5 GB to watch. Streaming in the browser means they are watching within seconds, while the original stays available for download if they actually need the master.

Swyvl uses multipart upload with automatic retry on every file and handles videos up to 100 GB — the originals stream in the browser untouched, with a full audit trail of who watched what and when.

Quick comparison of the practical options

For survey and drone work specifically, I went deeper on the file-sharing tools in Dropbox vs WeTransfer vs Box vs Swyvl for video. The short version, video-scoped:

The bottom line

If you are sending client video through a messaging app, an email preview, or an unlisted YouTube link, you are not sending your video — you are sending a re-compressed copy of it. The client judges your work by that copy. The only methods that preserve the exact quality you exported are cloud storage and a delivery platform, and only the delivery platform also lets the client watch it in the browser without a gigabyte-scale download.

For drone operators in particular, that quality is the product. A flythrough re-encoded to 720p by WhatsApp undersells the capture you flew the site to get.

Want to deliver video the way it was exported? See Swyvl for drone operators, or for a wider view of moving large spatial files, read how to send large LiDAR files to clients.

Create a free Swyvl account and upload your next video deliverable. It streams in the browser at full quality, the link is branded, and you can see exactly when the client watched it.

Your client should see the video you made — not the one an app made for you.