Making a Video File Smaller Without Making It Look Bad

The four controls

1. Resolution. The pixel dimensions of each frame. Halving both dimensions quarters the pixel count, which is the single largest lever available.
2. Frame rate. Frames per second. Halving it roughly halves the data, at the cost of motion smoothness.
3. Bitrate or quality target. How many bits per second the encoder may spend. The main quality dial once the first two are fixed.
4. Codec. The compression algorithm. A newer codec achieves the same quality at a lower bitrate, at the cost of encoding time and compatibility.

They are not independent. A 4K video at a low bitrate looks considerably worse than a 1080p video at the same bitrate, because the same bits are spread across four times as many pixels. Reducing resolution first usually beats reducing bitrate alone.

Resolution: start here

Most video shared between people is watched on a phone. A phone screen cannot display 4K meaningfully, so a 4K file sent to a phone is wasting roughly three quarters of its bytes before compression is even considered. Downscaling to 1080p is usually invisible and frequently the only change needed.

Frame rate: cut it only when the content allows

Frame rate is where people over-optimise. Halving 60 fps to 30 fps is a large saving and looks fine for most content. Going below 24 fps introduces visible stutter that no bitrate can hide.

• Screen recordings of mostly static content tolerate low frame rates well, sometimes down to 15 fps.
• Talking-head video is fine at 30 fps and often at 24.
• Sport, fast camera movement and gameplay need 30 fps as an absolute floor and benefit from 60.
• Never increase frame rate during conversion. It duplicates frames, adding size without adding smoothness.
• Halve rather than choosing arbitrary values. Going from 60 to 30 is clean; 60 to 25 requires resampling and can introduce judder.

Codec choice and the compatibility tradeoff

H.264 remains the correct default for anything you are sending to a person rather than publishing through a platform. The newer codecs are genuinely better, but a file that will not play is worth nothing regardless of how efficiently it was encoded. Where you control the playback environment, or the platform transcodes anyway, the efficiency gains are real and worth taking.

A working order of operations

1. Trim first. Removing thirty seconds of dead footage from the start beats any encoding setting, and costs nothing in quality.
2. Set resolution to what the viewer will actually use. For most sharing that is 1080p, for messaging apps 720p.
3. Set frame rate to the lowest the content tolerates, usually 30, halving from the source where possible.
4. Choose H.264 unless you know the destination supports something newer.
5. Set the quality target and encode a 20 second sample rather than the whole file.
6. Check the sample at full screen. If it holds up, run the full encode. If not, adjust one setting and sample again.
7. Only then, if it is still too large, revisit resolution before dropping quality further.

What over-compression looks like

• Blocking in flat areas, most obvious in skies, walls and shadows during motion.
• Smearing during fast movement, where detail dissolves and reassembles a moment later.
• Banding in gradients, where a smooth sky becomes visible stripes.
• Mosquito noise, a shimmer around hard edges and text that appears and disappears between frames.

All four mean the encoder has run out of budget for the resolution it was given. The fix is usually to lower the resolution rather than to raise the bitrate, because fewer pixels described well beats more pixels described badly.