halfsize / Windows

Windows 11 has no “compress to 20 MB”

You can right-click almost anything in Explorer, but not “make this video 20 MB”. The built-in tools compress on a quality scale, which is a different question from a size cap — and one of them is not compression at all.

What Windows 11 actually offers

The ZIP row is worth stating plainly because it is the first thing people try: video is already entropy-coded, so a general-purpose compressor finds almost nothing left to remove. A 40 MB clip becomes a 40 MB zip, one second later.

Clipchamp is a real compressor, but its dial is a resolution preset, not a byte budget. Exporting at 720p from a 20-minute 1080p recording can give you 300 MB or 90 MB depending on the content; there is no way to ask for 20 MB.

The arithmetic Windows does not do for you

A size cap converts to a bitrate: MB × 8000 ÷ seconds, minus audio and container overhead. For a 20 MB cap, after a 128 kbps audio track and 2% overhead:

Below about 80 kbps for video, no encoder produces something that still reads as video. That is a property of the budget, not of the codec.

The exact command, in PowerShell

Install FFmpeg once with winget:

> winget install Gyan.FFmpeg

Then two passes. The first analyses the clip and writes a log; it produces no video, so it goes to NUL — that is the Windows null device, and -f mp4 is required for FFmpeg to accept it. The example is a 60-second clip aimed at 20 MB, so 2,480 kbps for video:

> ffmpeg -y -i "holiday.mp4" -c:v libx264 -preset medium -b:v 2480k -pass 1 -passlogfile ffpass -an -f mp4 NUL

> ffmpeg -i "holiday.mp4" -c:v libx264 -preset medium -b:v 2480k -pass 2 -passlogfile ffpass -c:a aac -b:a 128k -movflags +faststart "holiday.20mb.mp4"

Two details that trip people up. First, quote paths that contain spaces — PowerShell passes them through fine, but the second pass must read the same log name as the first. Second, the first pass must be -an: audio does not change between passes, and encoding it twice wastes time.

That command assumes the clip is short enough for 2.48 Mbps to look acceptable. If your clip is ten minutes, the same 20 MB is 133 kbps and the output will look it — the command still runs, it just cannot invent bits.

Why the result can still miss the target

Two-pass ABR is an average over the whole file. A clip with a hard scene will overshoot in that scene and undershoot elsewhere; the total lands close, not exact. The container adds a little too. The practical answer is to aim 3–5% under the cap, which is what the tool below does on purpose.

The one-command version

> npx halfsize holiday.mp4 --to 20mb --dry-run

  target     20.0 MB
  plan       H.264  1280x720  2.46 Mbps  audio 128 kbps  2-pass
  scale      1920x1080 → 1280x720
  estimate   19.3 MB

> npx halfsize holiday.mp4 --to 20mb

  136 MB  →  19.45 MB   7x smaller   2.7% under target
  VMAF 88.3   slight softening

--dry-run is the part worth adopting even if you keep using FFmpeg by hand: it prints the bitrate and the resolution the budget can carry before ten minutes of encoding. The resolution choice is the difference between a soft 1080p file and a clean 720p one at the same size.

No global install is needed; npx caches it after the first run. If you would rather have it permanently: npm install -g halfsize.

FAQ

Related