Does converting MOV to MP4 lose quality? Only if you re-encode

It depends on one thing: whether the file is re-encoded. A MOV from an iPhone almost always holds H.264 or HEVC video with AAC audio, and an MP4 can carry those exact streams untouched. Copy them across and the picture is bit-for-bit identical — no loss at all. Re-encode them and you lose something, however high you set the quality.

The common exception is ProRes, which an MP4 cannot legally hold. Those files have to be re-encoded. Everything else is a plumbing job.

There are two different operations, and only one of them costs you quality

Almost every article on this subject hedges — "quality loss is negligible", "virtually indistinguishable". The hedging exists because the tools those articles recommend only know how to do one of the two things below. Once you can do both, the answer stops being a hedge.

A remux, or stream copy, opens the MOV, reads the compressed video and audio streams out of it, and writes those same bytes into an MP4 container. No frame is decoded. No encoder runs. There is no quality setting because there is nothing to decide. The output picture is the input picture, byte for byte.

A re-encode decodes every frame back to raw pixels and compresses them again with new settings. H.264 and HEVC are lossy, so the second compression discards detail the first one kept. A high quality setting makes that hard to see. It does not make it zero, and nobody should call a re-encode lossless, including us.

Why a MOV can usually become an MP4 for free

MOV and MP4 are not rival formats in the way that, say, JPEG and PNG are rivals. They are near-identical structures. MP4 was standardised from Apple's QuickTime container, and both are built on the same ISO base media file format: the same tree of boxes describing tracks, sample tables, timing and metadata. Two boxes with different labels holding the same goods.

That relationship is why the copy is possible at all. The video track in a modern iPhone MOV is already stored the way an MP4 wants it stored. The tool changes the label on the box, rewrites the index that says where each frame sits, and leaves the frames alone.

It also explains why the trip works in reverse. An H.264 MP4 remuxes back into a MOV container just as cheaply, which is what you want when a Mac editing app insists on QuickTime.

What travels intact through a copy

• The picture. Every frame, at the original resolution, frame rate and bitrate.
• The audio, when it is AAC — which it is on every iPhone recording.
• Rotation. Portrait clips carry a rotation matrix rather than rotated pixels, and it survives the copy. Our readout shows resolution already corrected for it, so a portrait clip reads 1080×1920 rather than the other way round.
• Duration and timing, including variable frame rate timing exactly as the phone recorded it.

The three files that cannot be copied

Before you assume yours is fine, check what is inside it. Three cases force a re-encode of at least part of the file.

ProRes. This comes out of professional cameras, out of Final Cut, and out of iPhone Pro models set to ProRes recording. It is an intermediate codec designed for editing, not delivery, and the MP4 specification has no place for it — the muxer refuses the copy rather than write a file nothing can play. ProRes files are also enormous, gigabytes per minute at high resolutions, which puts them well past what a browser tab can handle.

Uncompressed (PCM) audio. Screen recorders, field recorders and some cameras write raw PCM audio into a MOV, and an MP4 has no widely playable way to hold it. The fix is small: re-encode the audio to AAC and copy the picture, so the video quality question never arises. Recompressing sound once at a sensible bitrate is not something you will hear on dialogue or ambience.

Anything genuinely exotic — animation codecs, old QuickTime formats, camera-specific intermediates. Rare in consumer footage, common in archives.

Check the codec before you convert anything

You cannot tell any of this from the file name, the size or the icon. You have to read the header. Our in-browser codec checker parses the file in the page and prints the container, video codec and profile, resolution, frame rate, duration, audio codec and channel layout, bitrate, and how many subtitle and extra audio tracks are present. Nothing is uploaded to read it.

The MOV to MP4 converter shows you the same readout and then states, in words, whether it is about to copy the streams or re-encode them — before you press the button. That sentence is the whole answer to "will this lose quality", and you get it in advance rather than afterwards.

How to prove nothing changed

You do not have to take our word for it. Run the output back through the codec checker and put the two readouts side by side.

• Video codec and profile should match exactly — avc1 High 4.0 in, avc1 High 4.0 out.
• Resolution and frame rate should match exactly.
• Duration should match to the millisecond.
• File size will be close but rarely identical. The container index and metadata boxes differ slightly between MOV and MP4, so a few kilobytes either way is normal and expected. The video track inside is unchanged.

That last point trips people up. A file that shrank by 40 KB has not been compressed; it has been re-labelled. A file that shrank by 40 per cent has been re-encoded, and you should go back and check what the tool told you it was doing.

What a lossless remux still drops

Honesty cuts both ways. A stream copy keeps the picture perfectly, but it is not a perfect archival clone of the file:

• Subtitle tracks are dropped. The tool says so before it runs.
• Extra audio tracks are dropped. Only the first video stream and the first audio stream survive. This matters for downloaded films with commentary tracks and for multi-mic shoots.
• Timecode and camera-specific side data may not survive the container change.
• Files over 2 GB are refused in the browser, because a 32-bit WebAssembly heap cannot address them. Above roughly 300 MB the page warns you that it wants about three times the file size in free memory.

Keep your original until you have checked the converted file.

If you do have to re-encode, lose as little as possible

Sometimes the whole point is to change the codec — for a Windows PC, an old TV, an editor that refuses HEVC. Then quality loss is unavoidable, and the job is to keep it below the threshold where anyone notices.

• Use constant quality, not a fixed bitrate. Our presets default to CRF 20, 23 and 28. CRF spends bits where the picture needs them, so a static interview stays small and a handheld shot in a forest gets what it needs. A flat bitrate does the opposite of what you want on both.
• Do not change the resolution unless you need to. Leaving it at original avoids a rescale on top of the recompression.
• Do it once. Every re-encode compounds. Going MOV to MP4 to WhatsApp to MP4 again stacks three generations of loss, and generation three is visible. Convert from the original master each time.
• Keep the audio as it is if the codec is already AAC. There is no reason to recompress sound you are not changing.

The same reasoning applies across containers, incidentally — the logic for converting MKV to MP4 without losing quality is identical, because MKV holds H.264 and HEVC too. And if your actual goal is simply getting the file open on a PC, why a MOV will not play on Windows covers which of these two paths you need.

On a phone, the honest answer is different

Our Video Converter app uses the device's hardware encoder, which makes it far faster than a browser on long or 4K footage and gives it no file-size ceiling. It also always re-encodes — it has no stream-copy mode. That is a real trade-off, not a footnote: for a long 4K clip where speed matters more than the last few per cent of fidelity, the app wins; for a file you want returned untouched, the browser remux is the only one of the two that is genuinely lossless.