How to compress a video for email, WhatsApp, Discord and Slack without wrecking it

A one-minute 4K clip from a current phone is around 170 MB. Gmail stops at 25 MB, Discord at 10 MB without Nitro, and both refuse it flat. The fix is not a “quality” slider — it is arithmetic. A video’s size is its bitrate multiplied by its length, and every lever you have (trimming, resolution, frame rate, codec, bitrate) moves one of those two numbers. Below: the limits for each service, the sums behind them, what each of the site’s video tools does to the file, and a one-pass recipe.

The limits you are actually up against

Figures are as of 2026 and change without notice — check the app before relying on one. What happens above the cap, and whether the service re-compresses anyway, matter as much as the number.

Size is bitrate × duration, nothing else

Bitrate is how many bits the file spends per second. Divide megabits by 8 to get megabytes and the whole subject collapses into one line: size in MB ≈ Mbps × seconds ÷ 8. A clip at 8 Mbps for 60 seconds is 480 megabits, which is 60 MB. Run it backwards for a budget: a 60-second clip at 25 MB can spend 25 × 8 ÷ 60 = 3.3 Mbps; take 128 kbps off for audio and about 3.2 Mbps is left for the picture. Discord’s 10 MB gives the same minute 1.3 Mbps; stretch the minute to three and it drops to 0.44 Mbps.

For where phones start, the iOS camera settings (Settings → Camera → Record Video) quote roughly 60 MB per minute for 1080p at 30 fps in HEVC and about 170 MB per minute for 4K — 8 Mbps and 23 Mbps, with H.264 higher still. A 4K minute is seven times the Gmail cap and seventeen times Discord’s.

This is why “quality” sliders mislead: a quality setting (CRF in x264 terms) fixes the error per frame and lets the size land wherever it lands. When the constraint is a size, decide the size and let the bitrate follow. The one free lever is duration: halve it and the file halves at any quality.

Resolution and frame rate do the heavy lifting

Bitrate need scales almost linearly with pixel count. 4K (3840 × 2160) is 8,294,400 pixels per frame; 1080p (1920 × 1080) is 2,073,600 — four times fewer; 720p (1280 × 720) is 921,600 — nine times fewer than 4K. The encoder library behind our hardware path scales its default bitrate by (pixels ÷ 1080p pixels)^0.95, so 4K → 1080p buys roughly a 3.7× smaller file at the same visual quality, and 4K → 720p about 8×.

720p is enough for anything watched on a phone: a landscape video in a chat bubble occupies at most the screen width — 1080 to 1290 pixels on current phones — so a 1280-wide frame is already shown near 1:1. Keep 1080p for a laptop, projector or TV.

Frame rate is the second lever. 60 fps stores twice as many frames as 30; the saving from dropping to 30 is under half, because neighbouring frames predict each other well, but it is real and invisible outside sport and gameplay. The compress and resize tools here keep the source frame rate, so set 30 fps at recording time rather than trying to remove it afterwards.

Codec: H.264 for anyone, HEVC or AV1 only when you control both ends

• H.264 (AVC) in an MP4 with AAC audio plays on every phone, browser, TV and chat preview made in the last decade. It is the only safe answer when you do not know what the recipient has.
• HEVC (H.265)needs roughly 40% less bitrate for the same quality — the library we use budgets it at 0.6× the H.264 rate. iPhones record it by default (“High Efficiency”), but Windows may need the HEVC Video Extensions add-on, and many older Android devices, TVs and chat previews decode only H.264. The MOV vs MP4 guide covers that failure.
• AV1 is smaller again, about 0.4× H.264, but needs a hardware decoder from roughly 2020 onwards or a strong CPU. Fine for a YouTube upload, a bad idea for a family WhatsApp group.

Re-encoding is always lossy, so keep the original and compress from it, never from a previous output. For what MP4, MOV, MKV and WebM can hold, see containers and codecs explained.

What the tools on this site actually do to the file

All four video tools work in the browser tab, so a 2 GB original never has to leave your machine. They share one engine with two paths: a hardware path through the browser’s WebCodecs API (MP4, MOV, MKV, WebM and similar inputs whose codec the browser can decode, written to MP4, MOV, MKV or WebM; 4K stays 4K), and an ffmpeg.wasm fallback for AVI, FLV and WMV inputs, AVI, FLV and GIF outputs, and codecs the browser cannot decode. The fallback runs in a fixed 1 GiB heap, which is why it caps output at 1080p and cannot load inputs above about 2 GB. When you are on it with a source taller than 1080 lines, the options dialog says so: High-resolution source — output is capped at 1080p for in-browser conversion on this device. Pick 720p for a smaller, faster file.

Compress video

The compressor opens a dialog with five controls: Convert to (optional — AVI, FLV, GIF, MKV, MOV, MP4 or WebM; blank keeps the source container), Resolution (Keep original, 360p, 480p, 720p, 1080p), Target file size (MB, optional), and Mute video and Compress video checkboxes, the last ticked by default there. With no target size, the hardware path encodes at a pixel-scaled default of about 3 Mbps for 1080p H.264 (about 1.4 Mbps at 720p) and the ffmpeg path runs -c:v libx264 -preset superfast -crf 23; audio passes through untouched.

Type a target size and the tool does the arithmetic above with two refinements. The video budget is bytes × 8 × 0.93 ÷ duration − 128 kbps: 7% held back for container overhead, 128 kbps reserved for AAC audio (zero if you tick Mute), never below 50 kbps. With Resolution on Keep original it steps the frame down when the budget could not feed the source: under 300 kbps → 360p, under 700 kbps → 480p, under 1.5 Mbps → 720p, under 4 Mbps → 1080p. It encodes once, measures, re-encodes once on overshoot with the bitrate corrected by the observed ratio and a 5% margin, and if a hardware encoder still overshoots forces a final x264 pass with strict -maxrate control. A 60-second clip with a 25 MB target gets about 3.1 Mbps, so a 4K source is brought down to 1080p automatically; a 10 MB target for the same minute yields 1.17 Mbps and 720p.

Several files at once offer Same options for all or Set options per video and arrive as one converted-videos.zip. A single file above 1.5 GiB on the hardware path in Chrome or Edge opens a save dialog first and streams the output straight to disk, in one pass without the overshoot retry.

Resize video

The resizer is the same dialog with Compress unticked. You pick the height; width follows the aspect ratio (scale=-2:720 on the ffmpeg path, fit: contain on the hardware path). A bare resize re-encodes at roughly double the compress bitrate — 6 Mbps at 1080p — because its job is to keep quality, so for sharing tick Compress or set a target size in the same pass.

Trim video

The trimmer takes a start and end in seconds (type them, or scrub the preview and press Use current) and runs -ss start -to end -c copy: a stream copy, no decoding, so even a long 4K file trims in seconds and the kept frames are byte-identical. A copy can only begin at a keyframe, so the start may land a fraction of a second from what you typed. The output keeps the container as name_trimmed.mp4; one file at a time. A format ffmpeg cannot cut without re-encoding stops with Could not trim this file. Its format may not allow fast trimming — try converting it first, or a different clip.

Convert to MP4

The MP4 converter is the compressor with MP4 preselected and Compress unticked. Feed it a MOV, MKV or WebM whose video is already H.264, HEVC, VP9 or AV1, set nothing else, and the hardware path simply repackages the streams — no re-encode, same size, seconds. AVI, WMV and FLV are re-encoded with x264.

The recipe

1. Start from the original— not the copy WhatsApp already re-compressed, not last week’s attempt.
2. Trim first. Cut the fumbling head and dead tail in the trimmer. Every second removed is free.
3. Pick the number.Take the cap from the table and leave a margin: 24 for Gmail’s 25 MB (18 if the mail server may count the encoded size), 9.5 for Discord’s 10 MB. Divide by the trimmed length; under about 1 Mbps for a 1080p source, plan on 720p.
4. One pass in the compressor. In compress video: Convert to MP4 if the source is not one; Resolution blank for the automatic step-down; the target in the size box; Compress ticked; Mute ticked if the sound is wind noise.
5. Check before sending. Play the output to the end, read its size in Finder or Explorer, and sanity-check it: 24 MB × 8 ÷ 60 s ≈ 3.2 Mbps.
6. Or send a link instead. If the recipient is a person rather than a platform and the original is multi-gigabyte, do not compress it: share it device to device over an encrypted WebRTC connection between the two browsers — no size cap on our side, an optional PIN, both pages kept open until it finishes. The peer-to-peer guide covers when a relay is needed.

How to tell what you are starting with

You need duration and resolution; bitrate is size divided by duration. Finder’s Get Info (Command-I) and Windows’ Properties → Details both list dimensions and duration, and Windows adds Total bitrate. With ffprobe installed, one command gives everything:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,width,height,r_frame_rate \
  -show_entries format=duration,size,bit_rate \
  -of default=noprint_wrappers=1 clip.mov
# codec_name=hevc
# width=3840
# height=2160
# r_frame_rate=60/1
# duration=63.38
# size=612045210
# bit_rate=77256320        <- 77 Mbps: a 4K60 iPhone clip

That output tells the whole story: HEVC (convert to MP4/H.264 for Windows recipients), 4K60 (drop to 1080p or 720p), 63 seconds (trim what you can), 77 Mbps (a 25 MB target is a 25× cut, so 720p is the honest choice). One tool message needs a different plan: Conversion failed. The file may be unsupported, corrupted, or too large to process in this browser. on the fallback path usually means an input above about 2 GB or a codec neither path can decode — trim it shorter first, or convert it to MP4 elsewhere.

Common mistakes

• Compressing twice. Each encoder pass adds its own artefacts to the last. Go back to the original with a lower target, never to a previous output.
• Converting to GIF to “make it small”. GIF stores every frame in full with 256 colours and no inter-frame prediction; ten seconds of 480p GIF outweighs a minute of MP4. The target size box disappears when you pick GIF because GIF has no rate control to aim with. The GIF guide covers the cases where one is genuinely required.
• Screen recordings at native resolution and 60 fps.A Retina MacBook records at 2880 × 1800 or more — above the fallback path’s 1080p cap and far beyond what a chat window shows. Record at 30 fps (the screen-recording guide has the settings) and pick 720p or 1080p. A second trap: WebM from a browser recorder often carries no duration, and without one the compressor has no budget to compute, so the target box is silently ignored. Convert to MP4 first (the converter writes a proper duration), then compress.
• Expecting lossless at small sizes. 4K at 2 Mbps is a smeared mess; 720p at 2 Mbps looks fine. That is why the compressor steps resolution down with the budget.
• Forgetting the audio. 128 kbps of AAC is 0.96 MB per minute whatever you do to the picture: 2.9 MB of a 10 MB Discord budget on a three-minute clip. Tick Mute if the sound is irrelevant.
• Asking for a size the maths cannot reach. The floor is 50 kbps of video plus 128 kbps of audio, about 1.3 MB per minute; a fifteen-minute clip with sound cannot get under roughly 20 MB whatever you type, and the output simply overshoots. Shorten it, mute it, or send a link.