“Convert MOV to MP4” is one of the most common things people ask a video tool to do, and most tools answer it by decoding the whole file and encoding it again. Often that is unnecessary. MOV and MP4 are so closely related that the conversion can frequently be done by rewriting a few headers and copying the compressed video across untouched, in seconds, with no loss at all. Sometimes it genuinely cannot. This guide explains which is which, why the browser converter on this site takes the slower route, and how to find out what is inside your file so you can pick.
MOV and MP4 are the same box
MOV is Apple’s QuickTime file format. MP4 is the ISO base media file format, and it was standardised from QuickTime: the same tree of “atoms” (ftyp, moov, mdat), the same way of indexing frames, the same timestamp model. A MOV and an MP4 holding the same H.264 video and AAC audio differ in a handful of header fields and almost nothing else.
That means the conversion is, in the common case, a remux: read the streams out of one container and write them into the other. Nothing is decoded. The picture and sound are bit-for-bit what they were.
The remux command
ffmpeg -i in.mov -c copy out.mp4-c copy says: copy every stream as-is, do not touch the codec. FFmpeg reads the MOV, writes an MP4 around the same bytes, and is done in seconds. The output is the same quality as the input because it is the input, in a different wrapper.
If the file is going onto a web page, add -movflags +faststart so the index is written at the front of the file and playback can begin before the whole thing has downloaded. That is also a remux; FFmpeg just reorders the file after writing it.
If the output plays where you need it to, you are finished. The rest of this guide is about when it does not.
When the remux fails, or succeeds and then will not play
MP4 permits a narrower set of codecs than MOV, and the players at the other end permit narrower still. There are four cases that come up constantly.
HEVC (H.265)
Recent iPhones record HEVC by default. MP4 can carry HEVC, so the remux succeeds — but the resulting MP4 only plays where HEVC plays. Apple devices are fine. Windows has needed a separately installed HEVC extension for its built-in player, some Android devices decode it and some do not, and browser support is uneven. If the destination is “anyone”, the video usually has to be re-encoded to H.264, and that is a transcode of the video stream, not a remux.
One detail if you are remuxing HEVC for Apple players: FFmpeg may tag the stream as hev1 where Apple expects hvc1. Adding -tag:v hvc1 to the command fixes a file that QuickTime otherwise refuses.
ProRes
ProRes is Apple’s editing codec, common in footage from cameras and from Final Cut exports. The MP4 specification does not define it. FFmpeg will not put it in an MP4 without being forced, and a file produced by forcing it will not play in ordinary players. There is no remux path; the video must be re-encoded.
PCM audio
Some cameras, capture cards and screen recorders write uncompressed PCM audio into their MOVs. MP4 support for raw PCM is recent and thin, so a plain -c copy will either fail or produce a file whose audio most players ignore. The fix is a partial transcode, and it is cheap:
ffmpeg -i in.mov -c:v copy -c:a aac out.mp4The video is still copied. Only the audio is encoded, which takes seconds and is inaudible at normal bitrates. The picture is untouched.
Everything else in the file
Professional MOVs often carry a timecode track, a data track, or several audio tracks. MP4 muxers handle these inconsistently. Selecting just what you want is the usual answer:
ffmpeg -i in.mov -map 0:v:0 -map 0:a:0 -c copy out.mp4That takes the first video and first audio stream and ignores the rest. A related trap is chroma subsampling: cameras that record H.264 at 4:2:2 or 10-bit produce streams that remux fine into an MP4 and then fail on hardware decoders that only handle 4:2:0 8-bit. The file is valid; the phone is not equipped.
What the browser converter does instead
The MOV-to-MP4 converter here does not attempt a remux for a format change. It decodes the input and re-encodes it to H.264 video with libx264 at the ultrafast preset and CRF 28, with AAC audio, in 4:2:0 8-bit, and writes an MP4. (The one stream copy it does try is muting on its own, with the output left as MP4, MOV or MKV; if that copy fails it falls back to this re-encode.)
That is deliberate. The converter cannot know where the file is going. A tool that hands back an HEVC-in-MP4 file, technically valid, that then fails to open on the recipient’s Windows laptop has not done the job the person asked for. Re-encoding to H.264 and AAC produces the one combination that every device, browser and platform decodes, including in hardware. It also sidesteps every case above — ProRes, PCM, extra tracks, 4:2:2 — in a single path, which is what makes it reliable inside a browser tab where there is no second attempt.
The trade is real and it should be stated plainly:
- One generation of compression. At these settings that is not visible on typical footage, but it is not zero, and it is permanent in the output. What that generation costs is explained here.
- Time. A remux takes seconds. A re-encode inside WebAssembly on your own CPU takes real time on a long clip, and the input has to fit in the tab’s memory.
- Size.
ultrafastspends bits to save time, so the MP4 is sometimes larger than the MOV it came from, even from an HEVC source that was more efficiently compressed to begin with.
When is that the right trade? When compatibility is the point: sending the file to someone, uploading it somewhere that is picky, embedding it, or converting an iPhone HEVC clip for a device that cannot play HEVC. When is it the wrong one? When the MOV is a master — ProRes from a camera, an edit export you will cut again, anything you would call archival. In that case keep the MOV, and if you need an MP4 alongside it, remux on the desktop when the codecs allow and re-encode at a slower, higher-quality setting when they do not. The converter is for the first job, not the second.
The reverse direction, MP4 to MOV, follows the same logic; the other pairs on the converters page each state what they do to the streams.
How to tell what is inside a file
Do not guess from the extension. Ask:
ffprobe -v error -show_entries stream=index,codec_type,codec_name,profile,pix_fmt -of default=noprint_wrappers=1 in.movRead the result against this table:
| ffprobe reports | What to do |
|---|---|
h264 video, aac audio, yuv420p | -c copy. It is a remux and it will play everywhere. |
hevc video, aac audio | -c copy if every destination plays HEVC; otherwise re-encode the video. |
prores video | Re-encode the video. No remux exists. |
any video, pcm_s16le or similar audio | -c:v copy -c:a aac. Copy the video, encode only the audio. |
h264 with yuv422p or yuv420p10le | Remux is valid but expect hardware decoders to refuse it; re-encode for phones. |
| more than one video or audio stream | Add -map to select the ones you want. |
On a Mac without FFmpeg, QuickTime Player’s Show Movie Inspector lists the codecs; on every other platform ffprobe is the reliable answer.
The short version
- MOV and MP4 are the same structure. If the streams are H.264 and AAC,
ffmpeg -i in.mov -c copy out.mp4converts losslessly in seconds. - HEVC remuxes but may not play; ProRes cannot remux; PCM audio needs only the audio re-encoded.
- The browser converter re-encodes a format change to H.264/AAC on purpose, trading one generation and some time for a file that plays everywhere.
ffprobetells you which case you are in. The wider comparison of the containers themselves is in MP4 vs MOV vs MKV vs WebM, and the supported formats page lists what the editor reads and writes.