MOV to MP4: Why the iPhone Video Will Not Open on Windows

The extension names the box, not what is inside it

A video file has two independent layers. The container is the outer structure: it holds one or more streams, records how they line up in time, and carries an index saying where every frame begins. MP4, QuickTime's MOV, Matroska's MKV and WebM are all containers. The codec is what compressed the pictures into a stream in the first place — H.264, HEVC, VP8, VP9, AV1. A container mostly does not care which codec it carries, and a codec mostly does not care which container carries it. Which is why the same H.264 video can sit inside a .mov and a .mp4 and be, byte for byte in the parts that matter, identical.

MOV and MP4 are not even distant relatives. MDN's reference on media containers states that the MP4 file format derives from the ISO base media file format, which in turn derives directly from the QuickTime file format Apple developed. They use the same boxes, the same atom names, the same idea of an index. That family resemblance is exactly why so many people conclude that renaming the file will do the trick — and why renaming it so often changes nothing at all. If the codec inside was the problem, the new extension merely lets the player get one step further before it gives up.

What an iPhone actually writes

Apple introduced HEIF for photographs and HEVC for video with iOS 11 and macOS High Sierra, and every iPhone from the 7 onwards can record in them. The pitch is honest: the same picture in roughly half the storage. The camera setting that controls it lives at Settings, Camera, Formats, and it offers two choices — High Efficiency, which is the default and produces HEVC, and Most Compatible, which Apple's own support page says will make all new photos and videos use JPEG or H.264 instead. That single setting is the origin of nearly every MOV-will-not-play question, and it only affects recordings made after you change it.

Two details save a lot of confusion. First, the container does not change with the setting: an iPhone writes a .mov file either way, so the extension tells you nothing about which codec you have. Second, Apple already tries to help you. Its support page notes that when media is shared by AirDrop, Messages or email and the receiving device does not support the newer formats, it may automatically be sent in a more compatible one such as H.264 — which is why the clip your colleague received in a message opened fine, and the one you copied off the phone with a cable did not.

Why Windows is the machine that says no

HEVC is patented technology, and the licensing arrangement around it is why support is uneven in a way H.264's is not. Apple built decoding into macOS and iOS from High Sierra and iOS 11 onwards and absorbed the cost, so the file always plays on the machine it came from. Microsoft took the other route: it publishes an HEVC Video Extensions package in its own Store, sold rather than bundled, whose stated purpose is to let you play HEVC videos in any video app on Windows. A Windows machine that has never installed it will open the .mov, find a stream it cannot decode, and report anything from a codec error to a black rectangle with sound.

The browser is the second wall, and it is a different one. MDN's container reference marks the QuickTime container as unsupported in Chrome, Edge, Firefox and Safari, while MP4 is supported in all four. So a .mov holding perfectly ordinary H.264 will still refuse to preview in a web upload form, in a content management system or in an online editor — and there the container really is the problem, and a change of box really would be the whole fix. The same reference lists WebM as supported everywhere, which is why the third failure mode, the .webm that will not open in presentation software or a video editor, is the mirror image of the first.

Remux or transcode: two operations that look identical from outside

A remux opens the old container, lifts the compressed streams out untouched, and lays them into a new container. Nothing is decoded, nothing is re-compressed, and FFmpeg's documentation puts it plainly: with no decoding or encoding it is very fast and there is no quality loss. A two-gigabyte file remuxes in a few seconds, and the picture that comes out is the same picture, bit for bit. This is the correct operation whenever the codec is already acceptable and only the wrapper is wrong — an H.264 MOV that a web form refuses, an MKV download that a browser will not touch.

A transcode is the other thing entirely. It decodes every frame back to pictures and compresses them again with a different codec, which is the only way to turn HEVC into H.264 because the two describe motion in incompatible ways. It takes real time — minutes rather than seconds — and it costs a generation of quality, because the second encoder is compressing an image that already carries the first encoder's compromises. On a single pass from a good source that generation is usually invisible. Do it four times and it is not.

Being straight about this tool: it has no remux path. Whichever target you pick it decodes and re-encodes, so it will always cost you that generation, even on a file that only needed a new wrapper. That is a real limitation and worth knowing before you feed it a MOV you already know contains H.264 — in that case the better move is to keep the original and change what you send it to, if you can. Where the tool earns its place is the case it was built for: an HEVC recording that has to become an H.264 MP4, which is a transcode whichever program does it, done here without the file leaving your machine.

Finding out which one you actually have

The fastest diagnosis needs no software. If the video plays on the Mac or iPhone it came from and fails on a Windows PC, suspect the codec — that is the HEVC pattern almost every time. If it plays in a desktop player on the same machine but a web page or upload form refuses it, suspect the container, because the player is broad-minded and the browser is not. If it plays nowhere, including on the device that made it, the file itself is probably damaged and no conversion will help.

For a definite answer, open the file in VLC and look at the codec information: it names the video codec outright, so you will read either H.264 or HEVC and stop guessing. On a Mac, selecting the file and opening Get Info shows the codecs under More Info. On Windows, the file properties Details tab is inconsistent about it, so VLC is the reliable route. It is worth doing once on a file from your own camera, because the answer will be the same for everything that camera produces until somebody changes the setting.

What this converter runs, and why MP4 answers nearly every question

Three targets, and they are not equivalent. Choosing MP4 encodes the picture with libx264 at CRF 23 and the sound with AAC at 128 kbit/s, then writes the file with the faststart flag so the index sits at the front and the video can begin playing before it has fully arrived. Choosing MKV runs the same H.264 and AAC encoding into a Matroska container, without faststart, which is fine for a desktop player and useless for the web, since Matroska is not a container browsers accept. Choosing WebM takes a different road entirely: VP8 for the picture and Opus for the sound.

The WebM path carries a catch worth stating plainly. It does not use a quality target at all; it asks for a fixed video bitrate of 1 Mbit/s, whatever the source. On a 480p screen recording that is generous. On a 1080p clip it is an eighth of what YouTube recommends for that resolution, and on 4K footage it is a caricature. If you need WebM specifically — for a web page where file size matters more than fidelity — reduce the resolution first so the 1 Mbit/s has less work to do. For every other purpose, pick MP4: it is the one container the browsers, the phones, the editors, the presentation software and the upload forms all agree on.

Frequently asked questions

Can I just rename the file from .mov to .mp4?

Sometimes it works, and it is worth thirty seconds before you convert anything. The two formats are close enough relatives that a QuickTime file holding H.264 and AAC is frequently a valid MP4 already, and a player that was refusing on the extension alone will then open it. But the boxes are not identical — QuickTime allows structures and codecs that MP4 does not — so a renamed file may also be rejected outright or play with the wrong duration. Keep a copy of the original before you try, and if the renamed file misbehaves in any way, do the proper conversion instead.

Should I just set my iPhone to Most Compatible and forget about it?

It is a reasonable choice if you regularly hand videos to Windows machines, and it costs you real storage: HEVC delivers about the same picture in roughly half the bits, so H.264 recordings take noticeably more room on the phone and in your photo backups. The setting only affects new recordings, so it does nothing about the library you already have. A good middle path is to leave the phone on High Efficiency and convert the handful of clips that actually need to travel, which is the smaller job in almost every household.

How much quality does the conversion cost?

One generation, and at the CRF 23 this tool uses that generation is normally invisible on a first pass from a decent source. What makes it visible is repetition: convert, send to somebody who converts it again, then upload it somewhere that re-encodes on receipt, and by the fourth pass the softness in the shadows and the smearing on movement are obvious. The rule is to keep the original and always convert from that, never from a converted copy. The same rule is why you should not convert a file, compress it, then resize it as three separate steps if one step can do the job.

The conversion failed and the tool just said it could not convert the file.

The usual cause is memory rather than format. The whole file is loaded into the browser tab and the encoder works on it there, so a long 4K recording on a phone can exhaust the tab's memory and stop. Try a shorter clip, or the same clip on a desktop machine, before concluding the file is unsupported. The second cause is genuinely exotic input — a variable frame rate from a screen recorder, a stream with no keyframes, an unusual audio format — in which case extracting the audio separately and converting the video alone will often tell you which half is the problem.

Is HEVC always the culprit when something will not play?

No, and assuming so wastes conversions. AV1 is now common in downloads and is newer than HEVC, so older machines refuse it just as readily. A 10-bit or HDR H.264 or HEVC stream can fail on hardware that handles the 8-bit version of the same codec perfectly. Audio can be the blocker on its own — a video with an unusual audio track will sometimes show a picture and stay silent, or refuse outright. And a file that plays nowhere at all, including on the device that recorded it, is usually a truncated download rather than a codec question.