Compress Video for WhatsApp: Under the Send Limit
By Mark Fulton · 2026-08-20 · 11 min read
Everyone treats this as a size problem. It is really a quality problem wearing a size problem's clothes. To reduce video size for WhatsApp properly, give it a clean, already efficient 720p H.264 MP4 that fits inside the inline video cap, because WhatsApp runs its own compression pass on whatever you hand it. A file that is already efficient leaves that pass almost nothing to take. A huge phone recording gets crushed by it, and that is why the clip your friend receives looks worse than the one you shot. The cap itself is the boring half of the answer. The pass on top is the half that decides how the video looks.
There are also two different send paths inside the app, and they behave completely differently. One re-encodes, one does not. Most guides on this topic never mention that the choice exists.
What is WhatsApp's video size limit today?
Two numbers matter, and they apply to two different things.
The first is the inline video limit: the size ceiling for a clip sent through the photo and video picker, the one that plays right there in the chat bubble. As of August 2026 this sits at around 16 MB. Meta documents the same figure in its WhatsApp Cloud API media reference, which caps 3GPP and MP4 video at 16 MB for messages sent through the platform. The consumer app has historically tracked that number, though it can vary with connection quality and region.
The second is the document limit, which is far larger. WhatsApp's own announcement of 2 GB file sharing confirms you can send files up to 2 GB inside the app, protected by end to end encryption, raised from an earlier 100 MB ceiling. A video attached as a document is just a file, and it rides that much bigger allowance.
One honest caveat, and it is the reason so many pages on this subject are wrong. WhatsApp changes these numbers, rolls them out unevenly, and does not always publish the change loudly. Any article quoting a hard figure without a date attached is telling you what was true whenever it was written. Before you spend twenty minutes encoding to a target, check the number in your own app: attach a file you know the size of and watch whether it goes through as a video or gets refused. That takes thirty seconds and beats trusting a number, including this one.
Here is what a 16 MB envelope actually buys you, using the only equation that matters in compression, size equals bitrate times duration:
| Clip length | Total bitrate a 16 MB file allows | What that comfortably carries |
|---|---|---|
| 15 seconds | ~8.5 Mbps | 1080p, close to source quality |
| 30 seconds | ~4.3 Mbps | 1080p, good |
| 1 minute | ~2.1 Mbps | 720p, good |
| 2 minutes | ~1.1 Mbps | 720p, acceptable |
| 5 minutes | ~430 kbps | 480p at best |
| 10 minutes | ~215 kbps | 360p, visibly soft |
Those are arithmetic, not measurements: 16 MB is 128 megabits, divided by the clip's length in seconds. Subtract roughly 128 kbps for the audio track and the rest is your video budget. The full working is in video compression by the numbers, and the practical version, turning a target size into settings, is in compressing a video to an exact file size.
Read that table once and the shape of the problem is obvious. Short clips are easy. Anything past two minutes is not a compression problem, it is a trimming problem.
Why does WhatsApp compress a file you already compressed?
Because it has no idea what you sent it, and it has to guarantee delivery over a bad connection in a country you have never been to. So it normalises everything: one codec, one container, a resolution and bitrate it considers safe. That is a reasonable engineering decision for a messenger serving billions of devices. It is also the thing quietly ruining your video.
The mechanism is generation loss. Video codecs like H.264 are lossy by design. MDN's web video codec guide puts it plainly: most video codecs are lossy, the decoded video does not precisely match the source, and the more compression you achieve, the more detail and fidelity you lose. Crucially, the loss is not recoverable. When WhatsApp decodes your already compressed file and re-encodes it, it is not compressing the original footage. It is compressing your compression artifacts, faithfully preserving the blocking and smearing your encoder introduced, then adding its own on top.
Do that twice and you get the effect everyone recognises. A clip forwarded through four chats looks like it was filmed through a shower door. Each hop is another generation.
This flips the usual advice on its head. "Make it as small as possible" is exactly wrong, because a savagely compressed input gives WhatsApp's encoder a mess of artifacts to work from, and it will preserve them. What you want instead is a file that is small because it is efficient, not small because it was destroyed. Fewer pixels at a decent quality level beats many pixels at a terrible one, every time. That distinction is the whole subject of what compressing without losing quality actually means.
If your app offers an HD toggle when sending, turning it on raises the quality ceiling of that pass. It does not skip the pass.
Does sending as a document preserve quality?
Yes, and this is the single most useful thing to know about sending video on WhatsApp.
Attach the video through the document or file picker instead of the photo and video picker, and WhatsApp treats it as an arbitrary file. It does not decode it, does not re-encode it, and does not resize it. The bytes that leave your phone are the bytes that arrive. Combined with the 2 GB file ceiling, that means a 400 MB 4K clip can go through completely untouched.
The trade offs are real, and they are why this is not the default advice for everything:
| Sent as video | Sent as document | |
|---|---|---|
| Re-encoded by WhatsApp | Yes | No |
| Practical size ceiling | Around 16 MB, as of August 2026 | Up to 2 GB |
| Plays inline in the chat | Yes, with a thumbnail | No, shows as a file row |
| Recipient experience | Tap and it plays | Download first, then open in a player |
| Data cost to recipient | Small | Whatever the file weighs |
| Survives forwarding intact | No, each hop re-encodes | Yes, it is just a file |
Use the document path when the video is the deliverable: client footage, a wedding clip, anything someone will actually keep or edit. Use the video path when the video is a message: a five second dog clip does not need to arrive as a 300 MB download on someone's mobile data.
There is one wrinkle worth knowing. Some Android builds detect a video file sent as a document and offer to send it as a video instead. Decline that offer if quality is the point.
What resolution survives the re-encode best?
720p, in almost every case, and this surprises people who assume higher is safer.
The reasoning follows from the bitrate table above. WhatsApp's encoder has a fixed budget to spend. Hand it 1080p and that budget gets spread across roughly 2.07 million pixels per frame. Hand it 720p and the same budget covers about 921,600 pixels, less than half as many, so each one gets more than twice the bits. The 720p version arrives cleaner even though it started with less resolution, because it is not being asked to do the impossible.
Resolution is quadratic in a way that catches people out. Halving both dimensions quarters the pixel count. Going from 4K to 1080p removes about three quarters of the pixels before any quality setting is touched, which is why downscaling is the highest leverage move available and why you should resize before you compress, never after.
A few specifics worth having:
- 720p at 30 fps is the safe default for anything conversational: talking heads, screen recordings, phone footage of an event.
- 1080p is worth keeping only for clips under about thirty seconds, where the bitrate budget can still support it, or for anything going via the document path where nothing is being re-encoded anyway.
- 60 fps roughly doubles the number of frames competing for the same bits. Unless the content is fast motion where the smoothness genuinely matters, drop it to 30.
- Vertical 9:16 footage at 720p means 720 wide by 1280 tall, which is more pixels than 720p landscape. Budget accordingly.
- Screen recordings are the exception to almost everything here. Sharp text falls apart at low resolution far faster than faces do, so keep the resolution and accept a longer clip going out as a document.
How do you prep a clip in under a minute?
In order. The sequence matters, because each step makes the next one cheaper.
- Trim the dead air first. This is free compression with zero quality cost, and it is the only lever that is purely linear. Cutting a ninety second clip to forty seconds more than halves the file before you touch a single quality setting. Trim it at the top and tail, then look at the numbers again.
- Check the length against the table. If what is left runs past about two minutes, stop trying to compress it into the inline path. Send it as a document, or cut it into parts. Two minutes is roughly where the arithmetic stops cooperating.
- Drop to 720p. Resize unless the content is text heavy or under thirty seconds. Drop 60 fps to 30 while you are there.
- Run one quality based compression pass. Aim for visually clean rather than maximally small. A moderate quality target that lands at 12 MB beats an aggressive one that lands at 4 MB, because those 8 MB you saved are the exact detail WhatsApp's own pass will now have to invent around. Compress it here and check the output size.
- Confirm the current send limit yourself. Attach the finished file in WhatsApp and see whether it goes as a video. If it bounces, cut another ten seconds or step the quality down one notch. Do not re-encode the already compressed output repeatedly. Go back to the original and redo the pass with different settings, because every extra round trip is another generation of loss.
That whole sequence runs in the browser tab you are reading this in. The file is read into memory and processed on your own CPU by ffmpeg.wasm, so nothing is uploaded and nothing sits on a server waiting in a queue. Worth stating the honest limits too: the free tier caps input files at 200 MB and adds a small corner watermark to video exports, and because the work happens on your machine, a large clip takes as long as your laptop takes. Pro removes the cap and the watermark, and adds exact target size compression plus instant lossless trimming, which is the fastest way to hit a specific number like 16 MB without guessing. The one tool on the site that does send data anywhere is the transcript tool, which extracts and downsamples audio locally and then sends that audio for recognition. It says so on its own page.
Frequently asked questions
Why does my video look bad on WhatsApp?
Because WhatsApp re-encoded it after you sent it. Video sent through the photo and video picker is decoded and compressed again to a size and bitrate WhatsApp chooses, and lossy re-encoding never recovers detail, it only removes more. If the clip has already been forwarded a few times, each of those hops added another generation of loss. The fix is to control the input: 720p, a moderate quality level, trimmed short, or send it as a document so nothing is re-encoded at all.
Can I send a long video on WhatsApp?
Yes, but not through the inline video path at any watchable quality. A 16 MB envelope over ten minutes works out to roughly 215 kbps for everything including audio, which is genuinely poor. For anything past two minutes, either split it into parts or send it as a document, where the ceiling is 2 GB and the file goes through untouched. Trimming remains the best tool you have, since duration is a straight multiplier on file size.
Does sending as a file avoid compression?
Yes. When you attach a video through the document or file picker, WhatsApp handles it as an arbitrary file rather than as media, so it is not decoded, re-encoded, or resized. The recipient downloads the exact bytes you sent and opens them in a video player rather than watching inline. The cost is convenience: no thumbnail, no tap to play, and the recipient pays the full file size in data.
What resolution is best for WhatsApp?
720p for almost everything going through the inline video path. WhatsApp's encoder works with a fixed bit budget, and 720p asks it to cover less than half the pixels 1080p does, so each pixel gets more bits and the result arrives cleaner. Keep 1080p only for clips under about thirty seconds, or for anything sent as a document where no re-encoding happens. Screen recordings with small text are the exception and usually belong in the document path.
Trim it, resize it, and run one clean compression pass in the browser here before you send. WhatsApp gets a file it can leave alone, and the version that lands in the chat looks like the one you shot. The rest of the tools work the same way, on your machine, without an upload bar.
Sources
- Meta, WhatsApp Cloud API media reference
- WhatsApp Blog, 2 GB file sharing announcement
- MDN Web Docs, Web video codec guide