Convert MOV to WebM

That is the whole shape of this page. The MOV in front of you came out of Final Cut, Premiere or DaVinci Resolve, or straight off a camera card, and it was made to be edited rather than downloaded. It is measured in hundreds of megabytes, it may be ProRes, and it is the highest-quality copy of the material that exists.

The destination is the opposite of all of that: a landing page where the video is a texture behind some text, or a portfolio where a visitor on a phone should not spend eight megabytes finding out whether they like your work. Everything below is about getting from one to the other without making a decision you will regret when you look at the page on a slow connection.

It has to be said before anything else, because it is the single most common reason a designer converts a MOV specifically. Transparent video — a logo sting, an animated lower third, a product that floats over a page — is delivered as ProRes 4444 inside a QuickTime file, and the browser-side equivalent is VP9 with an alpha channel in a WebM. The path from one to the other looks obvious.

It is not available here. The conversion discards the alpha channel, so what comes out is opaque; and in practice a ProRes 4444 file will not decode in a browser at all, so it usually fails before it reaches that point. Producing alpha WebM needs a tool that can write it — an ffmpeg build, or an export preset in After Effects with a WebM plug-in. Keep the MOV as the master and get the transparent WebM from the software that made it.

VP9 for the picture and Opus for the sound, always. The bitrate follows the quality band and the resolution: the model treats VP9 as roughly forty per cent more efficient than H.264, which at 1080p puts the three bands near 1.1, 1.8 and 3.6 megabits a second against the 1.8, 3 and 6 an MP4 would get.

That efficiency is worth having and it is not the biggest lever on the page. A 4K master dropped to 1080p removes three quarters of the pixels before the codec ever sees them, and a background loop displayed 400 pixels tall gains nothing from being 2160. Set the resolution to what the element is actually rendered at, then argue about codecs.

This is the practical obstacle for this audience and it is worth planning around rather than discovering. The free tier takes files up to 100 MB. A ProRes master of a thirty-second title sequence can be several gigabytes; even an H.264 camera original at 4K is around 350 megabytes a minute — a phone writes 170 only when it is recording HEVC.

The answer is to export a smaller intermediate from the editor and convert that. A 1080p H.264 export at a moderate bitrate is a fraction of the master, decodes reliably in a browser, and gives the VP9 encoder a perfectly good picture to work from. Trimming to just the seconds that loop usually saves more than any encoder setting.

Put both files in one video element, WebM first and MP4 second, and let the browser choose. Browsers pick the first source they can decode, so a modern one takes the WebM and everything else falls through to the MP4. This is a two-line change in the markup and it is the difference between a saving and an outage.

For a background loop the rest of the attributes matter as much as the codec: muted, playsinline, loop, and preload set to metadata rather than auto so the video does not compete with the text for the first second of the connection. A poster image — a still taken from the same MOV — is what the visitor sees while all of that is being arranged.

Footage shot on a phone carries a rotation flag rather than rotated pixels, and Matroska-based containers like WebM have nowhere to keep such a flag. So the conversion rotates the picture for real and writes an upright image, which is the behaviour you want when the file is going into a page you do not control the playback of.

The consequence to watch is the aspect ratio in your CSS. A clip that reported itself as 1920 by 1080 with a rotation flag becomes a genuine 1080 by 1920 WebM, and a container styled for landscape will letterbox it badly. Check the dimensions of the output rather than the dimensions the camera claimed.

Writing VP9 needs a VP9 encoder, and that comes from the operating system rather than from this page. Chrome, Edge and Safari have one on essentially every current machine; some Firefox installations, particularly on Linux, do not, and the page says so before you choose a file rather than failing halfway through an encode.

The other half of the question is the source. A ProRes or 10-bit log MOV needs a decoder the browser very likely lacks, and the conversion stops with a message saying nothing in the file could be converted. There is no software fallback for either half: a codec compiled to WebAssembly is tens of megabytes and an order of magnitude slower than the hardware sitting beside it.

Video and audio, and nothing else. A QuickTime export can carry a timecode track, chapter markers, subtitle tracks and camera or edit metadata, and none of them are read. For a background loop that is irrelevant; for a self-hosted talk with chapters it means the chapters have to be rebuilt as data in the page.

Captions are the one worth planning for. A WebM served on your own site should have a track element pointing at a VTT file, which is better practice than an embedded subtitle track anyway — it is indexable, translatable and editable without re-encoding the video.

The material this page is for is often not public yet. A product launch, a client’s premises, a showreel under embargo, a piece of a campaign that has not run. The ordinary way to convert a MOV is to upload it to a converter chosen from a search result, which puts an unreleased asset on a server nobody has vetted.

Here the decoding and the VP9 encode both happen in the tab, using the codecs the machine already has. Nothing carrying the video goes out, and the network tab will confirm it. The practical benefit arrives at the same time: a large file converts at the speed of your processor rather than the speed of your upstream connection.