How to send large video files to clients without wrecking them

Video is where every other method gives up. A single minute of 4K footage can run to several gigabytes, an edit with rushes attached is a folder rather than a file, and the client on the other end usually wants to watch it today.

Here is how to get large video across without degrading it, and where the size actually comes from so you can make an informed decision about what to cut.

Why video is so big

Three numbers multiply together: resolution, frame rate, and bit rate. Bit rate is the one that matters most and the one people forget.

Source	Rough size per minute
Phone video, 1080p	60-130 MB
Phone video, 4K	350-400 MB
Mirrorless / cinema camera, 4K	1-3 GB
ProRes or other edit-grade codec	5-10 GB
Exported H.264 for review	20-60 MB

The gap between the last two rows is the whole game. The same ten-minute piece can be 60 GB of camera files or 400 MB of review copy, and which one you should send depends entirely on what the recipient is going to do with it.

Send the right version

Ask one question before you upload anything: is this for watching or for working on?

For watching — a client approving a cut, a stakeholder reviewing, anyone giving notes

Export an H.264 or H.265 MP4 at 1080p. Nobody gives better feedback because the file was 40 GB. A ten-minute review copy at a sensible bit rate lands around 300-600 MB, plays in any browser, and can be watched on a phone on a train.

This is not "sending a worse file". It is sending the file that fits the job. Reviewers ask for the master roughly never.

For working on — an editor, a colourist, a VFX house, an archive

Send the original. Do not re-encode, do not "just compress it a bit", and do not export to something smaller to be helpful: every generation of lossy compression throws away information the next person needs, and a colourist handed an H.264 export has been given a problem rather than a file.

This is when you accept the size and plan the transfer around it.

Getting a large file across

Once the file genuinely has to be large, the practical constraints are your upload speed and the reliability of the connection.

Do the arithmetic first. Upload speed is usually a fraction of download speed, and it is the one that matters here. On a 20 Mbps upload, 10 GB takes a bit over an hour in perfect conditions. On a 5 Mbps connection it is more than four hours. Knowing that in advance is the difference between a plan and an evening of surprises.

Prefer a wire. Ethernet over wifi, every time, for a transfer measured in hours. Wifi is where stalls come from.

Use something that resumes. This is the single most important property for video. A transfer that uploads the file as one continuous stream and restarts from zero on a dropped connection is unusable at this size. Chunked uploads — the file split into slices, each acknowledged, only the slice in flight lost when the connection blips — turn a four-hour upload from a gamble into a background task.

Here, files leave in slices and a failed slice retries by itself on a widening backoff. Pro accounts take 10 GB per transfer with 1 TB of storage, which covers most single deliverables; genuinely enormous jobs — a full shoot, a season archive — are still faster on a physical disk in a courier bag.

Do not zip video

Video files are already compressed, and heavily. A zip of a 4 GB MP4 comes out at roughly 4 GB, having taken time at both ends and left the recipient a file they have to extract before they can look at it.

The exception is bundling: if you are sending a folder of clips plus a project file and some notes, an archive keeps the structure intact. Do it for organisation, never for size.

Practical details that save a phone call

• Name the file properly. brand-spot-v3-1080p.mp4 tells the recipient what they have. final_FINAL_2.mp4 does not, and version confusion wastes more time than any upload.
• Say what it is in the message. Duration, resolution, and what you want back — approval, notes, or nothing.
• Match the expiry to the review cycle. A week is right for most feedback rounds. A month if it is going to several people who will get to it in their own time.
• Set expectations on size. A client on a laptop with a nearly full drive will appreciate knowing a 30 GB download is coming.
• Use H.264 for review copies, not H.265, unless you know the recipient's setup. It is the more universally playable of the two.

The short version

Decide whether the file is for watching or for working on. Export a sensible review copy for the first, send the untouched original for the second, and use a transfer that resumes so the size stops being a risk.

Related reading: why large uploads fail goes deeper on stalls and dropped connections, and how to send large files compares the methods in general.