Disclosure: I work on CompressVid, an online video toolkit. Every number here comes from our own test files. Sizes are as shown by the tool, which counts in MiB (1 MiB = 1,048,576 bytes). The bitrates are my own arithmetic:
size × 8 / duration.
"Just convert it to MP4, it'll be smaller" is one of those tips that is right often enough to survive. We ran five conversions while testing our converters. Two shrank the file a lot, one shrank it moderately, and two made it much bigger. Once you separate containers from codecs, the pattern makes complete sense.
Two layers in every video file
| Layer | What it is | Examples |
|---|---|---|
| Container | The box: it interleaves streams, stores timestamps and indexes, and holds metadata | MP4, MOV, MKV, WebM, AVI |
| Codec | The compression algorithm for each stream | H.264, HEVC (H.265), VP9, AV1, XviD; AAC, Opus, MP3 |
The container contributes very little to the file size, usually a small fraction of a percent for the index and headers. The bytes are in the encoded streams, so:
size ≈ (video bitrate + audio bitrate) × duration
"Converting" can mean two very different operations:
-
Remux: copy the existing streams into a new box (
ffmpeg -i in.mkv -c copy out.mp4). The size barely changes, and there is no quality loss. It only works when the target container supports the codecs. - Transcode: decode and re-encode, usually to H.264 + AAC for compatibility. Size is now set by whatever bitrate or quality the new encode chooses.
Most "convert to MP4" tools transcode, because their job is "plays everywhere", and that means H.264.
Five real conversions
| Conversion | Input | Output | Change | Avg bitrate in → out |
|---|---|---|---|---|
| WebM (VP9/Opus) → MP4, 40 s 1080p | 39.9 MB | 9.2 MB | −77% | ~8.4 → ~1.9 Mbps |
| HEVC MOV → H.264 MP4, 30 s | 50.3 MB | 26.0 MB | −48% | ~14.1 → ~7.3 Mbps |
| MKV → MP4 (H.264 1080p30 + AAC), 45 s | 65.5 MB | 37.4 MB | −43% | ~12.2 → ~7.0 Mbps |
| AVI (XviD/MP3) → MP4 (H.264 720p30 + AAC), 1:00 | 80.3 MB | 114.5 MB | +43% | ~11.2 → ~16.0 Mbps |
| MP4 → MOV (H.264 1080p30), 1:00 | 80.5 MB | 144.4 MB | +79% | ~11.3 → ~20.2 Mbps |
Look at the last column. Every size change is fully explained by the change in average bitrate. The extension didn't do anything by itself.
Why some shrink
- The WebM came from a source with a fairly generous bitrate for its content. The H.264 re-encode decided it needed far fewer bits for acceptable quality and dropped to roughly a quarter.
- The HEVC MOV is the interesting one. HEVC is generally more efficient than H.264, so you might expect the H.264 file to be bigger. It wasn't, because phone recordings use high real-time bitrates (hardware encoders favour speed over efficiency). A slower H.264 encode at quality-oriented settings still undercut it. Codec efficiency comparisons only hold at equal quality, and the phone's file wasn't anywhere near the efficiency frontier.
- The MKV shrank for the same reason. Its source bitrate was higher than the re-encode needed.
Why some grow
A transcode with quality-first settings (constant-quality modes like CRF) doesn't look at the input's bitrate. It spends whatever it takes to keep the new encode close to the decoded source. When the source was already compact, like an old XviD AVI at a modest bitrate or an efficiently encoded MP4, the new encode can easily choose a higher bitrate than the original.
Two extra effects are worth knowing:
- Generation loss costs bits. The new encoder sees the old codec's artifacts (blocking, ringing) as real detail and spends bits preserving them.
- Quality targets are absolute; source bitrates aren't. CRF 18 and CRF 23 mean "this quality level", not "this fraction of the input".
The MP4 → MOV case gets its own post, because it's a perfect example of a conversion that didn't need to re-encode at all.
A decision table for developers
Need different codec support? ──no──▶ remux (-c copy): same size, lossless
│yes
▼
Need a specific size? ──yes──▶ target-size compression (bitrate = size × 8 / duration)
│no
▼
Transcode at constant quality: size is whatever the content needs
Checking what's inside before you convert saves surprises:
ffprobe -v error -show_entries stream=codec_name,bit_rate,width,height \
-show_entries format=duration,size,bit_rate -of compact in.avi
If format=bit_rate is low and codec_name is something old like mpeg4 (XviD) or msmpeg4v3, expect a quality-first H.264 transcode to come out larger.
The same AVI, compressed instead
For contrast, the same 80.28 MB AVI went through a compressor with a 10 MB target. It came out at 9.77 MB (~1.4 Mbps average) as an H.264 MP4, versus 114.5 MB from the converter. Same input, same output container, same codec family. The only difference is the bitrate the encoder was told to spend.
Takeaways
- Containers are boxes. The size lives in the codec streams and their bitrate.
- "Convert" is either remux (size unchanged) or transcode (size follows the new bitrate).
- Transcoding a high-bitrate source usually shrinks it. Transcoding a compact source can grow it, by as much as +79% in our tests.
- If size is the goal, ask for a size, not a format.
If you'd rather see these effects on your own files than run ffprobe, our online video converter shows input and output sizes for each conversion, with nothing to install. It's a handy way to spot the "it got bigger" cases before you batch a folder.
Top comments (0)