MOV vs MP4: why iPhone videos misbehave on Windows and Android, and the fix

You shot a video on an iPhone, sent it to someone on Windows or Android, and got back “it won’t open” — or it opened with sound and a black picture, or with colours like a faded photocopy. The file ends in .MOV, so the obvious diagnosis is “wrong format”. It almost never is. MOV and MP4 are the same family of container; what trips other devices up is what the iPhone puts inside — HEVC video, 10-bit Dolby Vision, 60 fps 4K and a few Apple-only tracks. By the end of this guide you will be able to identify which of those your file has in under a minute, change the iPhone settings that stop it happening again, and convert the files you already have into an MP4 that plays anywhere without throwing away more quality than necessary.

MOV and MP4 are siblings, not rivals

MP4 is defined by ISO/IEC 14496-14, which sits on the ISO Base Media File Format (ISO/IEC 14496-12). That base format was contributed by Apple and is, in every way that matters, the QuickTime File Format that .MOV files use. Both are built from the same nested boxes (QuickTime calls them atoms): an ftyp box declaring the brand, a moov box indexing every track, and an mdat box holding the compressed frames. You can see the whole difference in the first twelve bytes. Run xxd -l 12 IMG_1234.MOV: bytes 4–7 are always 66 74 79 70 (ftyp) and bytes 8–11 are the major brand — 71 74 20 20, qt plus two spaces, for an iPhone recording; isom, mp42 or iso5 for almost any MP4. MOV additionally permits codecs MP4 does not list (ProRes, for one) and Apple-specific metadata tracks, which is why a blind container swap sometimes needs a flag or two.

So a player that refuses your file is almost never rejecting the container; it is failing to decode a stream inside it. Renaming .MOV to .mp4changes the extension and nothing else, which is why it “works” for some files (H.264 inside) and not others (HEVC inside). For the longer container-versus-codec story, see video containers and codecs explained.

What an iPhone actually records

Since iOS 11 (2017) the Camera app defaults to High Efficiency: video in HEVC (H.265) and photos in HEIC. Each generation since has added something else the rest of the world decodes less reliably.

There is also a quiet passenger in every iPhone recording: mebx timed-metadata tracks carrying camera motion and detected faces. ffmpeg lists them as Stream #0:2(und): Data: none (mebx / 0x7862656D). Players ignore them, but the MP4 muxer cannot tag them, which bites the moment you try a stream copy.

How to tell which case you are in

To confirm rather than guess: in Photos on the iPhone, the info panel (iOS 15 and later) shows resolution and frame rate (4K · 60 FPS) and an HDR badge. On a Mac, Finder’s Get Info lists Codecs: HEVC, AAC. With ffmpeg installed, one command is definitive:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,profile,pix_fmt,color_transfer,color_primaries,r_frame_rate,width,height \
  -of default=noprint_wrappers=1 IMG_1234.MOV

A Most Compatible recording answers codec_name=h264, pix_fmt=yuv420p, color_transfer=bt709. A default SDR clip answers codec_name=hevc, profile=Main. A Dolby Vision clip answers profile=Main 10, pix_fmt=yuv420p10le, color_transfer=arib-std-b67 (that is HLG) and color_primaries=bt2020; add -show_streams and a DOVI configuration record block appears with profile: 8 and compatibility id: 4. r_frame_rate=60/1 flags the 60 fps case.

Prevent it: the iPhone settings that matter

Settings → Camera → Formats

Switch Camera Capture to Most Compatible. Video becomes H.264 and photos become JPEG. The note on that screen tells you the cost: 4K at 60 fps and 1080p at 240 fps need High Efficiency, and so does HDR video, because Dolby Vision is always 10-bit HEVC. Files also grow — iOS’s own per-minute estimates are about 60 MB for 1080p30 in HEVC against 130 MB in H.264, and 170 MB against 350 MB for 4K30.

Settings → Camera → Record Video

Pick 1080p at 30 fps for anything destined for other people’s devices. Then turn off HDR Video (iPhone 12 and later): the camera records 8-bit SDR in BT.709, which removes the washed-out-colour problem entirely. You keep HEVC unless you also changed Formats, but 8-bit HEVC is far more widely decodable than 10-bit.

Settings → Photos → Transfer to Mac or PC

Automaticmakes the iPhone convert HEVC to H.264 and HEIC to JPEG when you import over a USB cable into Windows Photos or macOS Image Capture. It does not touch AirDrop or Messages — AirDrop sends the original bytes. On the Mac itself, QuickTime Player’s File → Export As → 1080p writes an H.264 .mov unless you tick Use HEVC, and Photos offers Export 1 Video (transcodes to H.264) versus Export Unmodified Original (HEVC untouched).

Or fix the receiving end

Windows 10 and 11 ship without an HEVC decoder. Microsoft sells HEVC Video Extensions in the Microsoft Store for US$0.99; once installed, Media Player, Photos and Edge decode HEVC and 10-bit files. VLC and mpv decode HEVC out of the box everywhere.

Fix it by conversion: remux or re-encode?

Two different operations hide behind “convert MOV to MP4”. A remux copies the compressed streams into an MP4 without decoding them: seconds, zero loss, only useful when the streams are already compatible. A re-encode decodes every frame and compresses it again with H.264: real time, a little quality, and the only thing that fixes HEVC, 10-bit or 4K60 for a device that cannot decode them. Read the ffprobe output and decide:

1. codec_name=h264 but it still will not play → remux; the container or metadata tracks are the problem.
2. codec_name=hevc, 8-bit, destination is a recent phone or a Mac → remux, or install HEVC support on the receiving PC.
3. codec_name=hevc, destination unknown, a TV, a web page or a Windows PC you do not control → re-encode to H.264.
4. pix_fmt=yuv420p10le → re-encode, and accept a colour shift unless the tool tone-maps. r_frame_rate=60/1 at 4K → re-encode at 1080p or 30 fps for TVs and sticks.

With ffmpeg on a desktop

The remux is one line, and the iPhone metadata tracks bite the first time you try it:

ffmpeg -i IMG_1234.MOV -c copy IMG_1234.mp4
# [mp4 @ ...] Could not find tag for codec none in stream #2, codec not currently supported in container

That is the mebx track. Drop data streams with -dn, or map only what you want: ffmpeg -i IMG_1234.MOV -map 0:v:0 -map 0:a:0 -c copy -movflags +faststart IMG_1234.mp4. The re-encode for universal playback:

ffmpeg -i IMG_1234.MOV -map 0:v:0 -map 0:a:0 \
  -c:v libx264 -preset medium -crf 20 -pix_fmt yuv420p \
  -c:a aac -b:a 160k -movflags +faststart IMG_1234.mp4

-pix_fmt yuv420p forces 8-bit 4:2:0, which is what Windows, browsers and TVs decode. For a Dolby Vision source that alone leaves the HLG curve in an SDR file; add tone mapping (ffmpeg built with libzimg): -vf zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p.

What the on-site converter does with an iPhone MOV

Convert to MP4first asks WebCodecs, through the mediabunny engine, whether this browser can decode the primary video track. If it can, the conversion runs on your device’s hardware decoder and encoder at the original resolution — a 4K60 file stays 4K60, and the options dialog says so: High-resolution source — converts at original size using your device’s hardware encoder.

Left at the defaults, the engine copies compatible tracks through — a container swap, so an HEVC MOV becomes an HEVC MP4 with the moov box moved to the front for instant playback. That is cases 1 and 2. To force the H.264 re-encode (cases 3 and 4), change any one of three things: tick Compress video, pick a Resolution (360p, 480p, 720p or 1080p; the default is Keep original), or type a number into Target file size (MB, optional). Each makes mediabunny decode and re-encode with the first codec in its MP4 list that your browser can encode, and that list starts with H.264. Mute video drops the audio track.

If WebCodecs cannot decode the source — HEVC on a machine without hardware HEVC support is the common case — the tool falls back to ffmpeg.wasm and runs -c:v libx264 -preset superfast, adding -crf 23 when Compress is ticked. Two limits apply on that path only: its fixed heap cannot hold frames above 1080p, so taller sources are scaled with scale=-2:1080 and the dialog warns output is capped at 1080p for in-browser conversion on this device; and inputs above roughly 2 GB cannot be loaded. On the hardware path, files over 1.5 GiB stream straight to a file you choose in a save dialog (Chrome and Edge). Output is <name>_output.mp4. Neither path performs HDR-to-SDR tone mapping, so a Dolby Vision source comes out with flatter colour — record SDR, or use the ffmpeg filter above when colour matters.

The same engine sits behind Convert to MOV, for the opposite direction, when iMovie insists on QuickTime for a Windows screen recording. Compress video is the same dialog with Compress pre-ticked and no target format, so it keeps the .MOV extension — pick MP4 in its Convert to menu for a smaller file and the compatible container in one pass.

Quality and size after HEVC → H.264

HEVC exists because it spends fewer bits than H.264 for the same picture; going back costs those bits. mediabunny’s bitrate model weights HEVC at 0.6 of H.264 for equal quality, so a matched-quality re-encode lands around 1.6 to 1.7 times the original size, and Apple’s estimates above show the same ratio (130 MB against 60 MB at 1080p30). Expect a 200 MB clip to come back at 300–350 MB if it must look the same.

The Compress option does not aim for matched quality. On the hardware path it uses mediabunny’s QUALITY_MEDIUM, which works out to 3 Mbps at 1920×1080 scaled by (pixels ÷ 1920×1080)^0.95 — about 11 Mbps at 3840×2160. An iPhone records 1080p30 HEVC at roughly 8 Mbps, so Compress usually shrinks the file even after the codec change, with visible softening in fast motion. Two things no re-encode gives back: a second lossy generation compounds artefacts, so always convert from the original; and 10-bit squeezed into 8-bit loses tonal steps, which shows first as banding in skies. For the best SDR from an HDR master, do it once on a desktop with the tone-mapping chain and -crf 18. Chat-app limits are in compressing video for sharing.

Common mistakes

• Converting the container but keeping HEVC. A remux produces a .mp4 that fails in exactly the same places. Run ffprobe on the output; if it still says hevc, nothing changed.
• Keeping 4K60 in H.264 and wondering why the TV still stutters. That is H.264 Level 5.2; many 4K decoders stop at Level 5.1, which is 4K at 30 fps. Drop to 1080p in the Resolution menu, or re-encode with -r 30.
• Converting a Cinematic clip before finishing the focus edits. The depth track and edit list only travel to Apple software. Finish in Photos, then convert the result.
• Silent output from an iPhone 16. If the audio is APAC and your browser cannot decode it, the video converts and the audio does not. Check the output has sound before deleting anything; the ffmpeg command above transcodes audio to AAC explicitly.

The same story for photos: HEIC

High Efficiency also decides your photo format, and a HEIC is a single HEVC intra frame in a HEIF container, so the same devices struggle with both. For the photos you already have, HEIC to JPG decodes the file with libheif in your browser and saves a JPG — one at a time through an editor with crop, rotate and quality controls, or a whole selection into a ZIP with an optional per-image size cap in KB. A file that fails with Could not read this HEIC photo usually uses a HEIF variant the bundled decoder does not know; macOS Preview is the fallback. Background is in HEIC photos explained.