Turn an iPhone .MOV into a .MP4 without re-encoding. The video and audio are copied across untouched, so there is no quality loss and no waiting for an encoder.
Drop an MP4 or MOV here, or click to choose one
Processed in this tab — the file is never uploaded
Drop it on the page or click to browse. Nothing is uploaded — the file is read directly in the tab, which is why there is no size limit imposed by a server and no wait for a transfer.
The tool lists the real tracks and codecs it found before doing anything: resolution, frame count, sample rate, channels. If the video uses a codec that cannot be passed through, it says so up front rather than handing you a file that does not play.
The container is rewritten and the encoded video and audio are copied straight across. There is no encoder involved, so this takes seconds on a file that would take minutes to re-encode, and the picture is unchanged.
The filename keeps its original stem with the new extension. Because the streams were copied rather than re-compressed, the result is the same quality as your source — not "almost the same".
A .MOV holding H.264 video and AAC audio already contains exactly what an .MP4 needs. Only the container differs, so the fix is to rewrite the wrapper and copy the streams — not decode and re-compress every frame.
The raw H.264 stream extracted from the output has the same MD5 as the one extracted from the input. Not "visually indistinguishable" — the same bytes. A conventional converter cannot say that, because re-encoding always loses something.
Work is proportional to file size rather than to frame count and complexity. Nothing is being compressed, so there is no encoder to wait for and no fan noise.
No upload, no queue, no account, no retention policy to read. That matters more for video than most file types — footage is often personal, and an upload-based converter means handing a copy to a stranger.
Codecs, resolution, duration and track layout are shown before conversion. If something cannot be handled, you learn that immediately instead of after a long wait.
It cannot change codec, and it says so. Remuxing an H.265 file gives you H.265 inside an MP4 — better supported as a container, but still H.265. The page does not pretend otherwise.
The common case is an iPhone. iOS records to .MOV, and while that plays fine on Apple hardware, plenty of things elsewhere will not touch it: older editing software, some upload forms, various TVs and projectors, and a fair amount of Windows software that predates broad QuickTime support. The irritating part is that the video inside is usually ordinary H.264 that those same tools would happily play — it is the wrapper they object to.
That is exactly the situation a remux is for. Because the encoded frames are already in a form MP4 accepts, converting is a matter of writing a new set of container boxes around the same data. Anything that decodes and re-compresses is doing enormous unnecessary work and throwing away quality to solve a filename problem.
It also matters for archiving. Every re-encode is a generation loss, so a library that has been converted a few times by well-meaning tools is measurably worse than the original. Copying streams keeps the footage exactly as the camera produced it, which is the only sensible way to normalise a collection of mixed containers.
One honest caveat about newer iPhones: if you record in HEVC (H.265), which is the default in "High Efficiency" mode, the output MP4 will still contain H.265. That is a genuine improvement for compatibility — MP4 is far more widely accepted as a container — but a player that cannot decode H.265 still will not play it. If that is your situation, the fix is a real transcode, which this tool deliberately does not attempt.
Both produce an .mp4. They are not the same operation, and the difference decides whether you should care which tool you use.
| Remux (this tool) | Re-encode (typical converter) | |
|---|---|---|
| What happens to the frames | Copied byte-for-byte | Decoded, then compressed again |
| Quality | Identical to source | Always some loss |
| Speed | Seconds — limited by disk | Minutes to hours — limited by CPU |
| Can change codec | No | Yes |
| Can change resolution | No | Yes |
| Can reduce file size | Barely — container overhead only | Yes, that is the point |
| Needs the file uploaded | No | Usually yes |
Use a remux when the container is the problem, which for MOV to MP4 it almost always is. Use a re-encode when you genuinely need different codecs, smaller files or lower resolution — and accept the quality cost that comes with it.
Not with this tool. The encoded video and audio are copied across without being decoded, so the output contains exactly the same frames as the input — the extracted H.264 stream has an identical checksum. Converters that re-encode do lose quality, because compressing already-compressed video always discards more information. If a tool takes minutes and warms up your laptop, it is re-encoding.
Because it is not doing the expensive part. Re-encoding means decoding every frame and compressing it again, which is heavy CPU work proportional to resolution, frame rate and duration. Copying streams is closer to a file copy — the cost is reading and writing bytes. A clip that takes a conventional converter several minutes finishes here in seconds.
Close, but not quite — and the difference is why renaming the file is unreliable. Both use the same underlying ISO base media file format, and QuickTime’s .MOV is the format MP4 was derived from, so the box structures are largely shared. But MOV permits things MP4 does not and identifies itself differently in its `ftyp` box, so a strict player can legitimately reject a renamed file. Rewriting the container properly produces a real MP4 rather than one that happens to work sometimes.
It will convert the container successfully, and the output will be a valid MP4 — but the video inside remains HEVC (H.265). That is often enough, because MP4 is much more widely accepted as a wrapper than MOV. It is not enough if the problem is the codec itself, for instance software that cannot decode H.265 at all. The tool shows you the codec before converting so you can tell which situation you are in.
No server-imposed one, since nothing is uploaded. The tool streams the file rather than loading it whole: the input is read in slices, converted media is released as it goes, and the finished file is written to browser-managed disk instead of held in memory. The largest file verified end-to-end is a 2.95 GB, four-hour recording, converted in about half a minute. Beyond that nothing is known to break — the page simply tells you when a file is bigger than what has been tested.
Only marginally, and not in the way you probably mean. Container overhead differs slightly between MOV and MP4, so the output may be a fraction smaller or larger. Genuinely reducing file size means re-compressing the video, which is a different operation with a real quality cost — and not something this tool does.
No. Reading, rewriting and saving all happen in the browser tab, which is why there is no upload progress bar and no queue. For video this is worth caring about: footage is frequently personal, and an upload-based converter means a copy of it exists on somebody else’s infrastructure under terms you did not read.