Why MP4 to MOV Gets Bigger: Re-encoding vs Remuxing Explained

Disclosure: I work on CompressVid. The test below is from our own MP4-to-MOV converter. Sizes are as shown by the tool (MiB). The bitrates are my own size × 8 / duration arithmetic.

Here's a result that looks like a bug but isn't: a 1-minute 1080p MP4 of 80.5 MB went in, and a 144.4 MB MOV came out. That's about 1.8× bigger, with the same resolution, the same length and the same codec family (H.264).

To see why, you need to know one thing: MP4 and MOV are nearly the same container.

MP4 and MOV are siblings

MP4 (ISO/IEC 14496-14) is derived from the QuickTime File Format, which is MOV. Both use the same "atom/box" structure (ftyp, moov, mdat, trak…), and both happily carry H.264 video and AAC audio. The differences are mostly branding (ftyp) and a few codec and metadata extensions.

So converting H.264/AAC MP4 to MOV can be close to free: just rewrap the existing streams.

# Remux: copy streams, change the box. Seconds, lossless, ~same size. ffmpeg -i in.mp4 -c copy -movflags +faststart out.mov 

What happened instead: a full re-encode

Our converter's page states it plainly: the video is re-encoded as H.264 + AAC in a QuickTime MOV container. A general-purpose converter has good reasons to do this: it has to accept any MP4, including HEVC, variable-frame-rate phone footage and unusual audio codecs, and still output something editors like Final Cut Pro and iMovie open reliably. The result in this test:

The encoder ran with quality-first settings. In constant-quality modes, the bitrate is an output of the encode, not an input. The encoder estimates what it needs to keep the decoded source looking the same, and the source here was an already-efficient H.264 encode. Re-encoding that faithfully took roughly 1.8× the bits, for two reasons:

1. The new encoder can't see the original scene, only the decoded frames. Compression artifacts in the source, like faint blocking and smoothed texture, now look like detail worth preserving.
2. Quality-first settings are tuned for "don't lose anything". For a file headed into an editor, that's the right bias. Editors and later exports will compress again, so you want headroom.

That's also why the same pattern showed up elsewhere in our tests: an XviD AVI grew from 80.3 MB to 114.5 MB when converted to MP4.

When you need a re-encode (and when you don't)

A partial re-encode is often the sweet spot:

# Keep video bits untouched, fix only the audio ffmpeg -i in.mp4 -c:v copy -c:a aac -b:a 192k out.mov 

Check first, decide second:

ffprobe -v error -select_streams v:0 \ -show_entries stream=codec_name,profile,r_frame_rate,avg_frame_rate,bit_rate -of default=nw=1 in.mp4 

If codec_name=h264 and r_frame_rate equals avg_frame_rate (constant frame rate), a remux to MOV will almost certainly open fine in Final Cut or iMovie.

Why tools don't always remux

If remuxing is faster and lossless, why would any converter re-encode? Because a remux only works when every stream is legal in the target container and plays well in the target app. A general-purpose online converter can't ask you whether your MP4 is HEVC with variable frame rate. So it picks the path that always produces an editor-friendly file, and accepts a bigger output. As a developer, if you control the input, remux. If you don't, re-encode and be honest with users about the size.

Takeaways

• MP4 and MOV share the same box structure. The container switch itself costs almost nothing.
• The size jump (80.5 → 144.4 MB in our test) comes from a quality-first re-encode, where bitrate is an output.
• Use -c copy when codecs are already compatible, and an audio-only re-encode when only audio is the problem.
• For a smaller file, compress to a target size. Converting won't do it.

If you need the editor-friendly path without touching the command line, the MP4 to MOV converter works online with nothing to install. Just expect the output to be larger, for the reasons above.