Convert MOV to MP4 on Mac Without Re-Encoding

All three were run on the same 8-second 1280×720 H.264 file. “Identical” means the video and audio stream MD5s matched the source exactly.

The top row wins on every axis that matters for a container swap. It is also free, and it ships with Homebrew rather than with us. That is the honest answer and it is the first thing this page should tell you.

Less than you would think. Both descend from the same QuickTime File Format; MP4 is the ISO standardisation of it. Both store their data in nested boxes called atoms, both use a moov atom for the index, and ffmpeg reports the same demuxer for both: mov,mp4,m4a,3gp,3g2,mj2. The extension is the loudest difference.

What varies is which codecs each container is permitted to carry. MOV is permissive — Apple uses it for ProRes, for uncompressed PCM audio, for timecode tracks, for Apple Animation with an alpha channel. MP4’s registered codec list is narrower. So the real question is never “MOV or MP4”, it is what is inside this MOV.

Two commands, and one that needs nothing installed.

The full picture. This lists every stream with its codec and profile:

ffprobe -v error -show_entries stream=index,codec_type,codec_name,profile \
  -of csv=p=0 input.mov

On the test clip that printed two lines:

0,h264,High,video
1,aac,LC,audio

The yes-or-no version. If you only want to know whether a remux will work:

ffprobe -v error -select_streams v:0 -show_entries stream=codec_name \
  -of csv=p=0 input.mov

h264 or hevc back means rewrap and stop. prores, dvvideo or mjpeg back means you have a real encode ahead of you.

Without installing anything. macOS ships avmediainfo at /usr/bin/avmediainfo, which reads files through AVFoundation — the same stack QuickTime uses — and tells you per track whether the system can decode it. Or open the file in QuickTime Player and press ⌘I for the inspector. Neither needs Homebrew.

ffmpeg -i input.mov -c copy output.mp4

-c copy is the whole instruction: demux the compressed streams, mux them into the new container, decode nothing. Two runs on the 3,270,762-byte source took 0.06 s and 0.16 s and produced 3,270,711 bytes — 51 bytes smaller, which is container bookkeeping and nothing else.

Verify it yourself rather than trusting the claim. Hash the streams on both sides:

ffmpeg -v error -i input.mov  -map 0:v -c copy -f md5 -
ffmpeg -v error -i output.mp4 -map 0:v -c copy -f md5 -
# MD5=ffd8f9aa5f71c044579f9c3c63847ba2  (both)

The audio hashes matched too, and a pixel-domain check came back at the only value that proves nothing changed: PSNR y:inf. A second fixture — a low-motion, screen-recording-like clip — behaved the same way: 148,016 bytes in, 147,965 out, same video hash.

When the codec inside is one MP4 cannot register. Handing ffmpeg a ProRes MOV with PCM audio produced an immediate, unambiguous refusal:

$ ffmpeg -i prores.mov -c copy output.mp4
[mp4 @ 0x…] Could not find tag for codec prores in stream #0,
            codec not currently supported in container
[out#0/mp4 @ 0x…] Could not write header (incorrect codec parameters ?):
            Invalid argument

It also left a zero-byte output.mp4 behind, which is worth knowing before you assume a silent success. Re-encoding that 9,363,172-byte ProRes Proxy file to H.264 took 3.16 seconds with ffmpeg and landed at 1,261,845 bytes. Smol produced 2,083,686 bytes in 3,072 ms from the same source, at a higher bitrate, and converted the PCM track to AAC without being asked — which is the part ffmpeg refuses to do for you.

One piece of folklore deserves retiring. MP4 can hold uncompressed PCM audio. ffmpeg 8.1.1 wrote our PCM track into an MP4 using the ipcm sample entry, and avmediainfo on macOS 27 reported “System support for decoding this track: Yes” with zero errors. It still is not what you want: that 8-second file spent 705 kbit/s on audio. Copy the video and re-encode only the sound:

ffmpeg -i input.mov -c:v copy -c:a aac -b:a 128k output.mp4

That took 0.19 seconds, cut 3,847,880 bytes to 3,270,711 — 15.0% smaller — and left the video stream hash untouched. Partial copies are the most under-used trick in this whole subject.

Two other cases force a real encode: an alpha channel, because MP4 has nowhere to put one, and a target device that only decodes H.264 when your file is HEVC. Neither is a container problem, and choosing settings for a genuine re-encode is its own subject.

Not on a single container swap. Smol’s video conversion path always re-encodes — it has no stream-copy mode — and on an already-H.264 source that is the wrong trade. Our test clip went from 3,270,762 to 4,489,384 bytes, a 37.3% increase, because the encoder was asked for high quality on a hard synthetic source and gave it. On a low-motion clip the same operation came back 5.0% smaller. Neither outcome beats 51 bytes and 0.06 seconds.

Where it does earn the money:

• The codec genuinely has to change. ProRes, DV and MJPEG all need a real encode, and 9,363,172 bytes to 2,083,686 in 3,072 ms with the audio handled is a fair trade for not learning ffmpeg’s audio flags.
• Mixed folders. Forty files where some are H.264 MOVs, some are ProRes, some are MKVs. One drop, one output setting, no per-file triage.
• Finder, not Terminal. A Quick Action means right-click, convert, done, for people who will never type -c copy.

Video output is limited to mp4, mov, webm and mkv. Smol reads AVI but cannot write it. The full format reference lists what it writes for every category, and Smol is $29 once with no subscription.

For one MOV that already contains H.264, it is not close. ffmpeg -c copy is instant, lossless and free. If you convert MOVs regularly and nothing else, install ffmpeg and stop reading:

brew install ffmpeg

QuickTime Player’s File → Export As is also free and already installed. It re-encodes to fixed presets with no quality control, which makes it a poor fit for this job specifically, and a perfectly reasonable one when you want 480p and do not care how you get there. All four Mac routes are measured side by side here.

For the reverse direction, or for anything with subtitle tracks and chapters, the rules are different: MKV to MP4 loses things a MOV does not.

MacBook Pro (Mac14,9), Apple M2 Pro, 10 cores, 16 GB, macOS 26A428. ffmpeg and ffprobe 8.1.1, Smol 1.0.34. Timings from /usr/bin/time -p, reported as the wall-clock real figure; Smol’s durations are its own reported job times.

Every fixture was generated on the machine with ffmpeg’s lavfi synthetic sources — no camera originals, no personal files, nothing downloaded. The 8-second 1280×720 clip was a testsrc2 pattern encoded with libx264 at CRF 23 plus 128 kbps AAC; the ProRes fixture was the same source at ProRes Proxy with 16-bit PCM audio. A test pattern is unusually hard to compress, so treat the re-encode file sizes as directional and the stream hashes as exact. All fixtures were deleted afterwards.