Cookies for analytics and advertising
We use cookies for analytics and advertising, both sent to Google. Refusing changes nothing you can see.Read the privacy page
Converting MOV to M4V puts footage you shot yourself into the file type Apple’s media library was built around. The QuickTime container becomes Apple’s MP4 variant and the picture is re-encoded to H.264, which older Apple TVs and iPads play without complaint. It runs in your browser.
Up to 100 files at once. Mixed formats are fine.
They convert one after another and download together as a ZIP.
MOV to M4V
The photo library is built around moments and the media library is built around titles. A wedding edit, a filmed recital, a talk somebody gave, a season of a child’s football — those behave better as entries in the Apple TV app, with a name and a poster, than as a wall of thumbnails in Photos where they scroll past at the speed of everything else.
M4V is the extension that world grew up on. iTunes used it for films and television, the Apple TV app inherited the convention, and a good deal of Mac software still treats a .m4v as a piece of programming and a .mov as a piece of footage. Converting is how you tell the library which of the two you meant.
M4V is MP4 with a different four characters on the end. Same ISO container, same boxes, same everything, which is why the advice on the MP4 to M4V page is to rename the file and stop reading. It is honest advice and it saves a re-encode.
A MOV is a different animal. QuickTime is the container MP4 was derived from rather than a synonym for it, and a QuickTime file announces itself in its header with a brand code of "qt " that a strict reader checks. Rename it to .m4v and you have a QuickTime file wearing an Apple video extension: some Apple software will play it anyway, and the software that validates rather than sniffs will not. That is a shaky foundation for a library you intend to keep.
The M4V comes out holding H.264 at High profile with AAC audio, regardless of what the MOV held. The target codec is fixed rather than copied from the source, and for this particular job that is a feature rather than a limitation.
A library is watched on old hardware. An Apple TV bought six years ago, an iPad the children use, a Mac mini acting as the media machine — several of those decode H.264 in hardware and HEVC either slowly or not at all. Recent iPhones record HEVC by default, so the raw footage is precisely the thing that stutters. Converting once, to the codec everything decodes, is what makes the library reliable.
The reason people associate M4V with locked files is FairPlay, the encryption the iTunes Store applied to films it sold. A protected M4V will not play outside Apple’s authorised software and cannot be converted by anything, in a browser or otherwise.
That is a property of files bought from a shop, not of the extension. The M4V produced here is an ordinary unprotected file: VLC opens it, an Android phone opens it, a television opens it. If you have a purchased M4V that will not convert, no converter is going to help and the honest advice is to use the app it was bought in.
Only the picture and the sound are carried over. A camera’s timecode track, any chapter marks and any subtitle tracks are dropped, and no metadata is written — the M4V has no title, no year, no description, no poster image. Dropped into a library it appears under its filename and nothing else.
So treat the conversion as step one of two. Whatever manages your library — the Apple TV app itself, or a tagger — is where the name, the date and the artwork go, and the artwork can come from the same recording: take a frame as a JPG and use that as the poster. Naming the files sensibly before you convert saves most of the work.
Vertical footage from a phone is stored as a landscape picture plus a flag saying how far to turn it. M4V uses the same container as MP4 and can hold that flag, so it is passed through unchanged and Apple’s players read it correctly.
The failure case is other software. If a clip ends up sideways on some player in the house, convert it again and choose a resolution at the same time — that forces the picture to be rotated for real during the encode, and a file that is upright in its pixels cannot be shown any other way. It costs a little quality and removes the argument permanently.
The quality band resolves to a bitrate that scales with resolution: roughly 1.8, 3 and 6 megabits a second at 1080p, and roughly 6.7, 11.2 and 22.4 at 4K. A library copy is the version everything downstream is made from, so the high band is usually the right call — you are trading disc space, which is cheap, against detail you cannot get back.
Resolution is where the real decision is. Very little in a home library benefits from 4K on a television across a room, and 1080p is a quarter of the pixels for a picture most people cannot distinguish at that distance. Converting 4K down to 1080p once here is also less work than asking a media server to scale every frame on every playback.
The free tier takes files up to 100 MB, and camera originals reach that quickly — an iPhone recording 4K at 30 frames a second writes around 170 MB a minute. A short piece converts comfortably; a two-hour recording of a school play does not, and a desktop encoder is the right tool for that.
Where this fits best is the finished thing rather than the rushes. One edited film per event, converted once, named and filed, is what a library wants. Converting every clip off the card produces a library nobody browses and a lot of duplicated storage.
Everything happens inside the browser tab, on your own processor, using the codecs your computer already has for playing video. Nothing carrying the file is sent anywhere, which you can check by opening the network tab while a conversion runs.
For home video that is not a small point. The material is family, houses and children, the ordinary alternative is uploading it to a converter chosen from a search result, and the destination is a machine in the same building. There was never a good reason for the file to make a round trip across the internet to get there.
| MOV | M4V | |
|---|---|---|
| Full name | QuickTime Movie | iTunes Video |
| File extension | .mov, .qt | .m4v |
| Media type | video/quicktime | video/x-m4v |
| Compression | Lossy — file size is bought with quality | Lossy — file size is bought with quality |
| First published | 1991 | 2005 |
| Published by | Apple | Apple |
| Specification | QuickTime File Format | — |
| Licensing | Published, not standardised | Published, not standardised |
| Standing today | Current | Current |
| Opens in a browser | Some browsers | Some browsers |
| Considered instead | MP4, MKV | MP4 |
M4V is a container rather than a single format. What actually plays is the codec inside it — usually H.264, HEVC and AAC — which is why two files with the same extension can behave differently on the same device.
QuickTime Player reads both MOV and M4V, so there is a way to check the result against the original without a second tool.
The two are aimed at different work: MOV at editing and broadcast, M4V at handing a finished file over and phones. That is worth weighing before converting, because the reason one exists is usually the reason the other is awkward.
MOV is Apple's format, published in 1991. The specification is QuickTime File Format, and it is worth reading if the file has to outlive the tool that wrote it.
M4V comes from Apple and dates from 2005. QuickTime Player, VLC and iTunes all read it.
Less safely than you can rename an MP4. MP4 and M4V are the same ISO container with two extensions, so renaming genuinely works there. A MOV is QuickTime’s own container and identifies itself as such in its header, so a renamed file is a QuickTime file with a misleading name — some Apple software forgives that and some does not. Converting produces a file that is what its extension claims.
No, and it cannot. The encryption that made M4V famous is FairPlay, applied by the iTunes Store to things it sells. Nothing in a browser can apply it and nothing here would want to. The M4V you get is an ordinary unprotected file that any player will open, which is what you want for your own footage.
H.264 at High profile with AAC audio, whatever the MOV held. That is deliberate rather than inherited: an older Apple TV, an iPad from a few generations back or a Mac without hardware HEVC will play H.264 without hesitating, and HEVC footage straight off a recent iPhone is exactly the thing they stumble over.
No. Only video and audio tracks are read, so chapter marks, subtitle tracks and the timecode track a camera writes are all left behind, and the M4V arrives with no title, artwork or description. Those are added afterwards in whatever manages the library — the metadata is what makes a file look like a proper library entry, and it is a separate job from the conversion.
It should not. The rotation flag a phone writes is carried across into the M4V unchanged, because both containers can store one. If you also choose a resolution, the picture is physically rotated during the encode instead, which removes any dependence on the player honouring the flag.
No. The conversion runs in this browser tab using your own hardware codecs, which suits the material — home video is the least appropriate thing to upload to an unknown server, and a file of a few hundred megabytes converts faster locally than it would upload.