Convert MOV to MP4

Convert iPhone and QuickTime MOV videos to MP4 right in your browser. Free and private, no upload, no size limit and no watermark.

🌐 Español

Drop your file here (.mov)

🔒 Private by design: your files are processed locally in your browser and never uploaded to any server.

Written and maintained by Last updated

What QuickTime’s MOV container holds that MP4 cannot

MOV and MP4 are closer relatives than their reputations suggest. MP4 is standardised as the ISO base media file format, and that standard was derived directly from Apple’s QuickTime File Format in the late 1990s. Both files are trees of nested boxes, both put a moov box in charge of describing the tracks, and both can hold the same H.264 video and AAC audio. That shared ancestry is why renaming a .mov to .mp4 occasionally seems to work.

Occasionally is the problem. QuickTime kept a much wider door open. A MOV can carry ProRes, Apple Animation with a real alpha channel, Motion JPEG, uncompressed PCM audio, timecode tracks and edit lists that MP4 either forbids or that no ordinary player expects to find there. A screen recording made by macOS routinely contains PCM audio; a clip exported from Final Cut is often ProRes. Rename either of those and the file becomes something with an MP4 extension that no MP4 decoder will touch.

That is the reasoning behind converting rather than rewrapping here. The sibling MKV to MP4 converter tries a lossless stream copy first and only re-encodes when the copy fails, which suits MKV because the codecs inside are usually MP4-legal already. This tool re-encodes unconditionally, because for MOV the odds of hitting something a rewrap cannot handle are high, and because the most common reason for converting is not the container at all.

HEVC is usually the real reason the file will not play

Since iOS 11 an iPhone set to “High Efficiency” records HEVC, also called H.265, inside that MOV wrapper. HEVC does its job well: roughly half the bitrate of H.264 for comparable quality, which is how a phone fits 4K video in a reasonable amount of storage. It is also patent-encumbered in a way H.264 is not, so support is patchy in exactly the places you need it. Windows asks for a codec extension, older Android builds decline, and plenty of smart TVs, projectors, car head units and web upload forms only understand H.264.

Nothing about the container fixes that. Move HEVC into an MP4 and it is still HEVC, and the Windows PC still shrugs. Converting the video stream to H.264 is what actually solves the problem, which is why that happens here whatever the input codec turns out to be. H.264 in MP4 with AAC audio remains the widest-support combination in existence, and +faststart is enabled so the moov box is rewritten to the front of the file and playback can begin before the download finishes.

CRF 18, 23 and 28

The quality picker maps to a single libx264 argument, the constant rate factor. High quality sets CRF 18, Balanced sets 23, and Smaller file sets 28. Nothing else moves between them.

CRF is a quality target rather than a bitrate target, so the encoder spends whatever bits each scene needs and a static talking-head clip ends up far smaller than the same length of handheld motion. A few points of CRF changes the output size substantially, which is what makes these three options meaningfully far apart rather than three shades of the same thing. Balanced is libx264’s own default and the right pick almost always. Reach for High quality when the file is a source for further editing, since compression artefacts compound each time footage is re-encoded.

The encoder runs at the fast preset in all three cases. A slower preset would find a slightly smaller file at the same CRF, but presets like slow or veryslow are simply not practical here, for a reason worth its own section. Audio is re-encoded to AAC at 128 kbps every time, which is a large saving on a screen recording that arrived as PCM and a fair trade on camera audio.

One CPU core, inside a browser tab

The engine is FFmpeg compiled to WebAssembly, and it is the single-threaded build on purpose. The multithreaded core requires the COOP and COEP response headers, and those headers break the ad iframes that pay for this site, so the threaded version is off the table permanently. Practically, that means one CPU core is doing work your desktop FFmpeg would spread over all of them. A short 1080p clip finishes quickly; a long 4K recording takes real time, and it is fine to leave the tab in the background while it works.

The upside is the one that matters for personal footage. Your video is never uploaded, so there is no 100 MB free tier, no queue, and no copy of your family clips sitting in someone’s temporary storage. The core itself is fetched once from a CDN on the first conversion, and after that your browser cache handles it.

Steps, and reading the result

  1. Drop a .mov file in, an iPhone recording, a QuickTime screen capture, an exported edit.
  2. Leave quality on Balanced unless one of the cases above applies.
  3. Convert, then download. The output keeps the original filename with an .mp4 extension.

Two things sometimes look wrong afterwards. If the video plays on its side, the rotation was recorded as container metadata and Rotate Video sets it explicitly. If HDR footage from a recent iPhone looks flat or unexpectedly dark, that is the missing tone mapping: no HDR to SDR conversion is applied, so the wide-gamut source is interpreted as ordinary video. Keep the original for anything where that matters, and convert a copy for sharing.

Frequently asked questions

What do the three quality settings actually change?

Exactly one number, libx264's CRF value. High quality is CRF 18, Balanced is 23 (the encoder's own default), and Smaller file is 28. Every other setting is fixed, so the audio is always AAC at 128 kbps and the encoder always runs at the "fast" preset regardless of which one you pick.

Which setting should I use for an iPhone recording?

Balanced, unless you have a specific reason not to. CRF 23 is visually very close to the source on ordinary handheld footage while cutting the file size substantially. Go to High quality when the clip will be edited or re-encoded again afterwards, since each generation of compression compounds, and only drop to Smaller file when you are fighting an upload or attachment cap.

Does it just rewrap the file, or is the video re-encoded?

Always re-encoded, both streams, even when the MOV already contains H.264 and AAC. That is a real cost compared with the sibling MKV to MP4 converter, which attempts a lossless stream copy first. MOV is re-encoded unconditionally because the containers so often hold things MP4 cannot carry, such as ProRes video or uncompressed PCM audio, and because the usual reason for converting is an HEVC file that a Windows PC will not decode, which a rewrap would not fix.

Why is it slow compared with a desktop converter?

The FFmpeg build here is single-threaded, so it uses one CPU core while a desktop install would use all of them. The threaded WebAssembly core needs COOP and COEP headers that break the ads paying for this site, so it is not an option. Expect a long 4K clip to take a while, and leave the tab open in the background.

My iPhone video is several gigabytes and the conversion fails

Both the input and the finished output live in the WebAssembly virtual filesystem at the same time, inside the browser tab's own memory, and that address space is finite. Very long or very high-bitrate recordings can exhaust it and stop with a generic error. Cut the clip into pieces with the Trim Video tool and convert each piece separately.

Will a QuickTime screen recording or a Live Photo convert the same way?

A Mac screen recording is an ordinary QuickTime MOV, so yes, it converts identically; screen content does tend to compress worse than camera footage at the same CRF, so High quality is worth trying if text looks smeared. A Live Photo is not a single MOV but a still image paired with a short clip, so export that clip as a .mov first and you will get a standalone MP4 of just the motion.

Related tools