How video compression works: bitrate, keyframes and codecs
Uncompressed 1080p video is about 3 gigabits per second — a minute would fill 22 GB. The MP4 on your phone is a few hundred megabytes for an hour. That thousandfold difference is video compression, and understanding its four ideas explains every setting in a compressor and every artefact you've ever seen in a stream.
Size is bitrate times duration
The single most useful fact: file size = bitrate × duration. Bitrate is the data allowed per second, and everything else — resolution, frame rate, codec, quality — decides how good the picture looks at that bitrate. A 60-second clip at 5 Mbps is 37.5 MB regardless of what's in it; at 1 Mbps it's 7.5 MB and looks worse. The bitrate calculator does the arithmetic for any length.
Where the compression comes from
Video is redundant in three ways, and codecs exploit all three. Spatially, nearby pixels are similar: like JPG, each frame is cut into blocks and transformed so that smooth areas compress to almost nothing while edges keep their detail. Temporally, consecutive frames are nearly identical: instead of storing a frame, the codec stores which blocks moved where (motion vectors) and the small difference that remains. Perceptually, eyes are insensitive to fine colour detail and to noise in busy areas, so colour is stored at lower resolution and quantisation is coarser where it won't be seen. A static talking head compresses superbly; confetti, rain and fast pans do not — there's little redundancy to remove — which is why sports streams pixelate on the action.
Keyframes, P-frames and why seeking stutters
Temporal prediction needs something to predict from. A keyframe (I-frame) is a complete picture; the frames after it (P- and B-frames) are stored as changes relative to neighbours, often a tenth the size. Encoders insert a keyframe every couple of seconds, which is why seeking lands on slightly different points and why a corrupted keyframe smears the next second of video. Streaming and screen-sharing use fewer keyframes for efficiency; editing formats use more — sometimes every frame — so that cuts are exact.
Resolution, frame rate and codec
Resolution sets how many pixels there are to compress: 1080p has 2.25× the pixels of 720p and needs roughly that much more bitrate for the same quality — the reason "compress" usually means "downscale". Frame rate matters less than people think; 30 fps is plenty for talking and screen content, 60 for games and sport. The codec sets efficiency: H.264 is the compatible baseline, H.265/HEVC and VP9 need about 30–50% less bitrate for the same quality, AV1 less still, at the cost of slower encoding and patchier support (WebM vs MP4: containers, codecs, and which one to send covers the formats). Two encodes of the same file at the same bitrate can differ a lot in quality depending on the encoder's speed preset — slower is better.
Shrinking a file sensibly
- Trim first. Seconds you don't need are the cheapest bytes to lose — the trimmer.
- Downscale to the destination. A phone screen or a chat window never shows 4K; 720p at 2.5 Mbps looks the same there and is a fifth the size.
- Set bitrate by content. Talking heads and screen recordings look fine at 1–2 Mbps in 720p; action needs 4–8.
- Don't re-encode repeatedly. Each generation loses quality; keep the original and compress from it.
- Remember audio. 128 kbps AAC is transparent for speech; a 320 kbps track on a 1 Mbps video is a quarter of the file.
Browsers can do this on-device now — real-time re-recording with the compressor, or true re-encoding through WebCodecs in the MP4 converter — so shrinking a video for WhatsApp no longer means uploading it to a website first.
Sources and further reading
The claims in this guide rest on these references, which were checked when the guide was last updated. Spotted an error? The contact page says how to report it.