Inside specific tools
FFmpeg: Convert MOV to MP4 Without Losing Quality (The Lossless Remux)
The command is ffmpeg -i input.mov -c copy output.mp4, and the part that makes it lossless is -c copy: instead of decoding and re-encoding your video, FFmpeg lifts the compressed streams out of the MOV box and writes them into an MP4 box untouched. No pixels are recomputed, so no quality can change. The operation is called a remux, it takes seconds even on large files, and it is the right answer to "convert MOV to MP4" far more often than an actual conversion. This page's commands were run and checked on FFmpeg 9 before writing - including the case where FFmpeg refuses, which matters as much as the one where it works.
What -c copy actually does
A video file is two things wearing one filename: compressed streams (the H.264 video, the AAC audio) and a container that bundles them with timestamps and metadata. MOV and MP4 are both containers from the same family, so a stream that fits one usually fits the other. Re-encoding decodes every frame and compresses it again - that is where generations of quality die. Stream copy skips all of it: the exact bytes of the video and audio tracks are copied into the new container, and only the packaging is rewritten. On a two-second test clip, the .mov came out at 217,295 bytes and the remuxed .mp4 at 217,244 - the MP4 was actually a few hundred bytes smaller, because container bookkeeping differs slightly. Same stream, same quality, and the difference you can measure is a rounding error.
Check the result, not the promise
You do not have to trust the word "lossless" - the file can be interrogated. Run ffprobe on both files and compare what is inside:
ffprobe -v error -show_entries stream=codec_name,codec_type -of csv=p=0 input.mov
On the test clip, both the MOV and the remuxed MP4 report the same two lines: an h264 video stream and an aac audio stream. Identical codecs in, identical codecs out - that is the whole definition of a lossless container change. (The same probing technique reads deeper properties like pixel formats; the alpha channel check page covers that in detail.) If the codecs match on both sides, the remux did its job, whatever any conversion dialog told you.
When FFmpeg refuses: the codec, not the command
The remux only works when the codec inside the MOV is one the MP4 container actually accepts. Feed it a ProRes master and FFmpeg stops rather than mangling your file:
[mp4 @ ...] Could not find tag for codec prores in stream #0, codec not currently supported in container
That error is the MP4 muxer saying its format has no label for ProRes - the same reason MP4 cannot carry your transparency: ProRes 4444 masters, including any alpha channel they hold, belong in QuickTime containers, and squeezing them into MP4 is not a repackaging job at all. Two practical footnotes from the same test: FFmpeg exits with an error code rather than writing a broken file, but it does leave a zero-byte output.mp4 behind - delete it so it cannot masquerade as a failed conversion later. And if your source is ProRes, the honest conclusion is not "find a more clever converter" - it is that an MP4 of this file must be a re-encode, with the quality cost that implies.
When you genuinely need to re-encode
Two situations. First, the codec will not fit - ProRes and a few other editing formats have no MP4 seat, so a real encode is the only path. Second, the file must get smaller - and this is the part the search completion "convert mov to mp4 reduce size" gets backwards: a remux changes size by a few hundred bytes, ever. Size lives in the codec and its bitrate, so shrinking a file means re-encoding it:
ffmpeg -i input.mov -c:v libx264 -crf 23 -preset medium -c:a aac output.mp4
On the same test clip this produced a genuinely smaller file, and on real footage the drop is dramatic. The two flags worth understanding: -crf is the quality dial for x264, running from 0 (lossless territory, enormous) to 51 (unwatchable), with 23 as the default and roughly 18-28 as the sane working band - lower keeps more detail and costs more space. -preset trades encoding time against compression efficiency; medium is the default and fine. Every re-encode is a generation loss, so keep the original: encode a delivery copy, never over your master.
What a remux will not fix
- File size - the stream is copied byte for byte; only a re-encode shrinks it.
- Player compatibility with an odd codec - if the codec was the problem, the same codec is now in a different box.
- Missing transparency - repackaging never adds an alpha channel; if the export went black, that is an export-settings problem, covered in the transparent export guide.
- A "conversion" that a website demands for its own sake - for H.264 content, a renamed file sometimes plays fine, but a remux is honest and costs seconds; the reasoning is in MOV vs MP4.
Pick in twenty seconds
- H.264 or HEVC inside, just need the .mp4 extension → -c copy remux; instant, lossless.
- FFmpeg says "Could not find tag for codec" → the codec cannot sit in MP4; re-encode, or keep it as MOV/ProRes.
- The file must be smaller → re-encode with -crf (23 default, lower is better); keep the original.
- Unsure what is inside the MOV → ffprobe first; the codecs decide everything else.
- The clip still needs its background removed first → start at the main guide, then pick your export box.
Disclosure: This site is reader-supported. Some pages contain affiliate links; this one doesn't.