To send large video files to clients, keep your camera-original (your 10-bit or 4K master) untouched, deliver a browser-playable H.264 web version via a link, and skip every method that recompresses your footage — email, messaging apps, and YouTube all silently degrade quality. Your client streams the footage in their browser without downloading gigabytes or installing a player, and you can download the original master if you need it.
That is the short version. The long version is specific to video, and it is a different problem from sending a point cloud or a CAD drawing. I run a spatial data company, and drone operators tell me the same thing constantly: the footage looks stunning on their monitor, then arrives at the client looking soft, washed out, or — worse — refusing to play at all. The file is enormous, something along the way recompressed it, and the codec the camera recorded in is not the codec the client’s laptop can decode.
This guide is the video-specific companion to my general piece on sending large files to clients in construction and survey and the how-to on large LiDAR files. If you want the quick answer rather than the full walkthrough, there is a short version at the best way to send large video to a client.
Why drone video is its own delivery problem
Spatial files are all large, but video adds three failure modes that a point cloud never has: it gets bigger faster, it gets quietly recompressed in transit, and it is recorded in a codec the client probably cannot play. Let us take each one.
1. Size: 4K and 10-bit footage is enormous
A modern drone shoots 4K at high bitrates, and many shoot 10-bit. Here is roughly what you are dealing with:
| Footage | Resolution / bit depth | Typical bitrate | 5-minute clip |
|---|---|---|---|
| 1080p H.264 | 1080p, 8-bit | 40 Mbps | ~1.5 GB |
| 4K H.264 | 2160p, 8-bit | 100 Mbps | ~3.7 GB |
| 4K HEVC, 10-bit | 2160p, 10-bit | 130 Mbps | ~4.8 GB |
| 5.1K / 6K HEVC | up to 6K, 10-bit | 200 Mbps | ~7.5 GB |
| ProRes 422 HQ (4K) | 2160p, 10-bit | 700+ Mbps | ~26 GB |
A single five-minute orbit of a site can be 5 GB. A full inspection flight is tens of gigabytes. Email caps out at 25 MB — three orders of magnitude short — and even WeTransfer’s free 2 GB tier will not hold one clip.
2. Recompression: email, messaging apps, and YouTube degrade it silently
This is the trap that catches drone operators out, because the file moves successfully but arrives worse.
- Messaging apps (WhatsApp, iMessage, Slack) aggressively recompress video to save bandwidth. A 4 GB 4K clip becomes a soft, blocky 50 MB version. The client sees that version and assumes that is the quality you shot.
- YouTube and Vimeo re-encode everything you upload to their own delivery codecs and bitrates. Sharing an unlisted YouTube link is sending the client YouTube’s compressed copy, not your footage. It also wraps your professional deliverable in someone else’s player and ads.
- Email, where the file is small enough to attach at all, may also recompress inline video previews.
The damage is invisible to you because you are looking at your master on your own machine. The client is looking at a degraded copy. They never see what you actually captured.
3. Codec: 10-bit HEVC will not play for the client
Even if you transfer the file perfectly, the client may not be able to open it. Most high-quality drone footage is 10-bit HEVC (H.265). Standard Windows playback and many browsers do not ship an HEVC decoder, and 10-bit pushes it further out of mainstream support. ProRes is worse — it is effectively a Mac-only, pro-editing format.
So the client double-clicks the file and gets a black screen, an audio-only track, or a “codec not supported” error. To them, you sent a broken file. The fix is transcoding to 8-bit H.264 for delivery — which I cover in depth in drone video formats explained.
4. Playback: nobody wants to download 6 GB to press play
Even with a working codec, the download-then-open model is hostile. A client on a normal connection waits ten minutes for a 6 GB file before they can watch a five-minute clip. They will not do this twice. Delivery should mean streaming — the client clicks, the video plays in the browser, done.
Want the quick version? I wrote a short, skimmable answer to “how do I send large video to a client” here: best way to send large video to a client.
The workflow: keep the original, deliver a web version
The correct approach separates two jobs that operators usually try to do with one file.
- The master is your camera-original — 10-bit HEVC, ProRes, whatever the drone recorded. You keep this untouched. It is your editing, grading, and archival copy. You never recompress it for delivery.
- The web version is an 8-bit H.264 MP4 you transcode specifically for delivery. It plays in every browser and on every phone, with no plugins. The client streams this.
Deliver both: the H.264 web version for instant browser playback, and the master available as a download for the rare client who needs the full-quality file for their own editing.
Why H.264 for the delivery copy
H.264 is the most universally compatible video codec on earth. Every browser decodes it, every phone plays it, no codec pack required. You lose nothing meaningful for review purposes — at a sensible bitrate, an H.264 web version of a 4K clip looks excellent and streams fast. The 10-bit and ProRes advantages matter for grading, not for a client confirming the inspection covered the right roof.
How Swyvl handles this automatically
Doing this by hand means running every clip through a transcoder, hosting the output somewhere, and stitching together a player and a download link. Swyvl does it for you.
You upload the camera-original. Swyvl stores it untouched — no recompression on the way in — and automatically transcodes a browser-friendly H.264 web version. Your client gets a branded link, clicks it, and the footage streams in a browser video player immediately. No download, no codec packs, no “it won’t play” email. The original master sits behind a download button for anyone who needs it.
Uploads use multipart transfer, so a 30 GB ProRes clip survives a network blip instead of failing at 90%, and the cap is 100 GB. And you get a full audit trail: who opened the link, when, and which clips they actually watched.
Method comparison for large video
| Method | Max size | Streams in browser | Recompresses your video | Plays 10-bit HEVC for client | Branding | View tracking |
|---|---|---|---|---|---|---|
| 25 MB | No | Sometimes | No | Email signature | Read receipt only | |
| WhatsApp / iMessage | ~100 MB | In app | Yes — heavily | N/A (degraded) | None | No |
| WeTransfer | 2 GB free / 200 GB Pro | No | No | No (raw download) | Minimal | Download count |
| Dropbox / Google Drive | 2-50 GB | Plays some formats | No | Often no | None | Basic |
| YouTube / Vimeo (unlisted) | Large | Yes | Yes — re-encoded | Their player | Their player | Their analytics |
| Swyvl | 100 GB | Yes | No (master untouched) | Yes (auto H.264 web version) | Full white-label | Full audit trail |
For a deeper head-to-head against the cloud-storage tools specifically, see Dropbox vs WeTransfer vs Box vs Swyvl for video.
Practical tips for delivering drone video
Transcode the delivery copy, archive the master
Make 8-bit H.264 your default delivery format. Keep the 10-bit or ProRes original as your archival master. Do not make the client’s playback copy carry your grading copy’s requirements.
Never route footage through a messaging app
If a client asks you to “just WhatsApp it across,” push back. They will receive a recompressed shadow of your work and judge your quality on it. Send a link instead.
Warn clients about master download sizes
If a client genuinely needs the original, tell them the size upfront. “The master is 6 GB — about ten minutes to download” sets the right expectation, and most clients will happily stick with streaming the web version.
Group footage with the rest of the deliverable
A drone job is rarely just video. The footage usually ships alongside an orthomosaic, a point cloud, and a report. Group it all by capture session so the client sees one organised delivery, not a scattering of links — the same session-based approach I describe in the LiDAR delivery guide.
The bottom line
Sending large video is not really a transfer problem — it is a quality preservation problem. The footage moves easily enough; what breaks is the quality (recompression), the playability (codec), and the client experience (download-then-pray). Solve those three and delivery becomes trivial: keep the master, deliver an H.264 web version, stream it via a link, track who watched.
If you fly drones for a living, this is worth getting right — your footage is the product, and clients judge it on what lands in their browser. Swyvl is built for drone operators: upload the original, we transcode and stream the web version, you get a branded link and an audit trail. Create a free account and send your next flight properly.
Your 4K footage is too good to arrive looking like a WhatsApp forward.