Send Large Videos Without Compression
You filmed something in 4K, sent it to a friend, and what they watched was a soft, blocky version with a fraction of the detail. Nothing went wrong: the messaging app did exactly what it is designed to do. This guide explains why chat apps re-encode video, what that costs, and the three ways to deliver the file you actually recorded.
Why chat apps compress video
A minute of phone video at 4K/30 is roughly 350–450 MB. Multiply by the messages sent every day and a chat service would be a video-hosting company with a text feature. So the apps transcode: the sender's phone re-encodes the clip at a lower resolution and bitrate before upload. It saves the provider storage and bandwidth and, for a quick clip watched on a phone, most people never notice. The trade-off is that the original is gone from the recipient's point of view.
Most apps offer an escape hatch (send as a “document” or “file” rather than as a “video”), which skips the transcode but still uploads through the provider, still needs the same app on both sides, and still has a per-file ceiling (commonly around 2 GB at the time of writing; check your app's help page, as these change).
What compression actually removes
Video codecs throw away detail the eye is least likely to miss: fine texture, subtle gradients, fast-moving edges. A re-encode at a lower bitrate makes each of those worse, and a second re-encode (the recipient forwards it) compounds the loss. The symptoms are familiar: smeared grass, banding in skies, blocky shadows, and audio that goes from stereo to a thinner mono track. None of it is recoverable afterwards; there is no “enhance.” The only fix is to send the original bytes.
Three ways to send the original
| Method | Original bytes? | Realistic ceiling | What you accept |
|---|---|---|---|
| Cloud drive link | Yes | Your quota (free tiers: 5–15 GB total) | Upload then download, an account on your side, a stored copy in the cloud |
| Chat app “send as file” | Yes | ~2 GB per file (app-dependent) | Same app on both sides; still goes through the provider |
| Direct browser link (P2P) | Yes: SHA-256 verified on arrival | No protocol limit; receiver-dependent (below) | Both devices online at once; a slow uplink is a slow transfer |
The direct link, step by step
- On the receiving device, open
app.sharedrop.organd click Receive. On a laptop, prefer Chrome or Edge: they write the video to disk as it arrives, so there is no size problem. - On the sending phone, open the ShareDrop.org app (or the same address), tap Send → Videos, pick the clip, and scan the receiver's QR code.
- Approve both sides. The transfer moves the file in 64 KiB chunks and hashes them as it goes; “done” means the receiver's copy hashes identically to yours (how that check works).
How long it takes, honestly
On the same Wi-Fi the file moves at the router's speed — a 1 GB clip in well under a minute on Wi-Fi 5/6. Across the internet, the sender's upload speed is the limit, and home uploads are often 20–50 Mbps: a 1 GB video is then three to seven minutes, and there is no service that can make it faster because the bottleneck is your own line. If the app shows Encrypted relay rather than Direct, expect a little extra latency but roughly the same throughput (the measurements).
Receiver limits to know
- Safari and Firefox assemble the file in memory and are capped at 512 MB per file. A 4K clip longer than about a minute needs Chrome or Edge on the laptop, or the ShareDrop.org mobile app, which streams to storage (the reason).
- Keep the sending phone awake. A locked screen can pause the link; the transfer resumes from the last verified chunk rather than restarting, but only once the phone is back.
- Watch the storage on the receiving phone. A 3 GB file needs 3 GB free — obvious, and the most common reason a large transfer is refused.
How big videos actually are
Apple publishes estimates in the Camera settings; they are a good guide for any recent phone.
| Setting | HEVC (“High Efficiency”) | H.264 (“Most Compatible”) |
|---|---|---|
| 1080p at 30 fps | ~60 MB per minute | ~90 MB per minute |
| 1080p at 60 fps | ~90 MB per minute | ~150 MB per minute |
| 4K at 30 fps | ~190 MB per minute | ~350 MB per minute |
| 4K at 60 fps | ~400 MB per minute | — |
| 4K ProRes at 30 fps | ~6 GB per minute | |
A three-minute 4K clip is over half a gigabyte; a minute of ProRes is bigger than most people's entire photo collection. This is why the receiving side's limits matter for video specifically: a 512 MB cap that never troubles photos is reached by three minutes of 4K.
Formats, and playback on the other side
Sending the original bytes means the recipient gets the original format, and the original format is not always what their device expects.
- HEVC (H.265). The default on iPhones and many Android phones. Plays natively on any recent phone and Mac; on Windows it needs the HEVC Video Extensions from the Microsoft Store (a small one-time purchase, or a free manufacturer version on some PCs); on Linux, VLC or mpv handle it.
- Dolby Vision HDR. iPhone video is HDR by default. On a display or player without HDR support it looks flat and washed out. The file is fine; the screen is not showing what is in it. Turning off HDR video in the iPhone camera settings before recording avoids the problem for footage meant for others.
- ProRes. Made for editing, not for sending: enormous, and only editing software handles it well. Convert to HEVC before sending unless the recipient is the editor.
- H.264. Plays everywhere. If compatibility matters more than file size, set the phone's camera to Most Compatible before recording.
If you must compress, do it well
There is a difference between the compression a chat app does (fast, aggressive, and to a low target), and compression done to keep quality. HandBrake (free, every platform) with the H.265 or H.264 encoder, constant quality around RF 20–22, the original resolution and frame rate, and audio passed through untouched, produces a file a fraction of the size that most people cannot tell from the original on a phone. Keep the original; compress a copy. And trim first: cutting a ten-minute clip to the two minutes that matter loses nothing, and on a Mac, QuickTime Player's trim does not re-encode at all.
Three things that catch people out
- The video is not actually on the phone. With iCloud Photos set to “Optimise iPhone Storage,” older videos are thumbnails on the device and the full file lives in iCloud. Picking one triggers a download of the original first, which needs both time and free space; on a slow connection this looks like the transfer has stalled before starting. The app shows it as a preparation step.
- Mail offers to shrink it. When you attach a video in the iOS Mail app, it asks Small / Medium / Large / Actual Size. Anything but Actual Size re-encodes. Gmail and Outlook apps make similar offers with less obvious wording.
- AirDrop can convert too. Sending HDR or HEVC video to an older Mac, AirDrop may offer a “compatible” version; if you accept, the recipient gets a transcode. Decline to send the original.
One video, many people
A direct transfer is one sender to one receiver. For a video that ten relatives want, that is ten transfers, each needing the other person present: workable for a family on a call, tedious otherwise. The honest tools for one-to-many are a shared cloud folder or an upload-and-link service, accepting that a copy then lives on a server for as long as the link does. A middle path: send the original directly to one person who will keep it, and let the rest have the compressed chat-app version, which is all most of them will ever watch.
If the recipient just wants to watch it
Then compression is fine, and a chat app is the right tool: instant, asynchronous, and the quality loss will not matter on a phone screen. Send the original only when the original is the point: editing, archiving, printing frames, or a client who will notice.
