Compress a video for WhatsApp

The published numbers

WhatsApp's own help (WhatsApp video help) gives 64 MB and 100 MB as the default limits, depending on the connection. This site records them as the figures stated at the source, checked 2026-09-21, and does not map them to the HD setting, which WhatsApp treats as a separate quality choice. Documents are another route: WhatsApp documents lists up to 2 GB.

The compressor's WhatsApp preset writes a 64 MB target into the size box, which is the same figure, with no margin. If a file lands within a few percent of the limit, trim a few seconds so the byte count is clearly under it.

Measured: five minutes of 1080p into 64 MB

Every measured number on this page comes from one run set on 2026-10-18: the live /tools/video-compressor/ page driven by headless Chrome/154.0.8037.92 on 13th Gen Intel(R) Core(TM) i9-13900K (32 threads, 126 GB RAM, Linux 7.0.0-34-generic), software WebCodecs with no GPU. The sources are synthetic files made with ffmpeg (ffmpeg version 6.1.1-3ubuntu5): a test pattern, with temporal noise added where the label says noisy, plus a 48 kHz sine tone. They are not camera footage. Outputs were saved through the page's Save button and measured with ffprobe. The raw records are in the repository at docs/evidence/runs/2026-10-18-video-target-runs.json. A phone or a machine with a hardware encoder can land at different sizes, and that was not measured.

Same preset, different results

Balanced at the original size produced 68.9 MB for the 300 second noisy clip, over the 64 MB target by 8%. On the 180 second clean clip the same setting gave 61.9 MB, under the target, at 1080p. The setting is identical and the verdict flips with the content. That is the reason to check the result card each time.

For the noisy clip, 720p MP4 reached 61.4 MB and the Smallest preset reached 62.1 MB as WebM. Choose 720p if you want an MP4. The Smallest preset wrote WebM (VP9 video, Opus audio) in every run, not MP4. Check that the app you send to accepts WebM before you choose it.

One run is missing from the table. A 100 MB target on the 300 second noisy clip did not finish in two attempts, so this page has no result for it. The failure is in the evidence file and its cause was not investigated.

The 100 MB figure is the larger of the two published limits. WhatsApp decides in the app which one applies to a given connection.

What stays in the file

The MP4 files the compressor wrote still carry container tags (major_brand, minor_version, compatible_brands, creation_time). The creation_time value is the time of the encode, not of the original recording. For a file you plan to publish, run the output through Verify metadata removed and read Remove MP4 metadata.

If you send a photo or video as a document to keep full quality, the original file goes as it is, with its metadata. The WhatsApp HD photo article covers the photo side, and the platform metadata lab lists which platforms have been measured. WhatsApp itself has no measured entry yet.

A 12 second ffmpeg clip, 29 October 2026

ffmpeg 6.1.1-3ubuntu5 wrote a 1280×720 test pattern with temporal noise and a 440 Hz tone. The source command used libx264 ultrafast at 25000k video, minrate 22000k, maxrate 25000k, bufsize 25000k, and AAC at 160k. The output command used libx264 medium at 800k video, maxrate 800k, bufsize 1600k, AAC at 96k, and +faststart. The compressor button on the video compressor was not used for this row. 38452098 bytes is under 64 × 1,000,000 and under 64 × 1,048,576, so this row sits under the published 64 MB figure on either reading of MB. The five-minute browser table above is still the cap measurement.

The output is smaller: 38452098 bytes in, 567974 bytes out. ffprobe duration on the output is 12.010000 seconds. The record is docs/evidence/runs/2026-10-29-comp-fixtures.json.

FAQ

More tools

Video Compressor · Video size limits by platform · Video compression guide · Remove MP4 metadata · Verify metadata removed