Convert WebM to MOV

Footage arrives from places nobody shoots in. A client sends a screen capture their browser made. A reference clip comes off a website. A colleague’s browser-based recorder produced the interview. A remote meeting tool exported the session. All of these hand you a WebM, and a WebM is a delivery format designed in 2010 to move video to browsers cheaply, not to be cut.

The result is an import dialogue that either greys the file out or accepts it and then behaves badly. Adobe ships no VP9 decoder; Final Cut Pro does not read the container; After Effects is inconsistent about it across versions. Converting to MOV replaces both halves of the problem at once — a container Apple wrote and a codec every editor decodes in hardware.

This is the single most important sentence on the page. MOV is a container, and ProRes is a codec that often lives inside one — the two get used interchangeably in edit suites, and they are not the same thing. What is written here is H.264 video with AAC audio inside a QuickTime wrapper.

That distinction has consequences on a timeline rather than in a player. ProRes is an intermediate codec: every frame stands alone, which is why scrubbing and rendering are fast and why the files are enormous. H.264 is a delivery codec that describes most frames as changes to other frames, which is why the file is small and why seeking backwards costs the machine work. If the edit is long, transcode this MOV to ProRes once inside your NLE and cut from that instead.

The encoders available to a web page are the ones the operating system exposes through WebCodecs, and that set is deliberately narrow: H.264 and VP9 for video, AAC, Opus, FLAC and PCM for audio. ProRes is Apple’s own, licensed, and reachable through Apple’s tools rather than through a browser tab.

Saying so is more useful than pretending otherwise. A converter that offered "MOV (ProRes)" and quietly wrote H.264 would produce a file that behaves exactly as this one does and an editor who cannot work out why their timeline is slow. If ProRes is a hard requirement, this conversion is step one of two, and Compressor, Media Encoder or your NLE’s own transcode is step two.

The resolution control matters more for an edit than for playback. A 4K screen capture on a 1080p timeline is scaled every time it is rendered or scrubbed, and dropping it to the sequence resolution here removes that work permanently rather than paying for it on every preview.

The list runs from 2160p down to 360p, with the width following automatically. Asking for a resolution the source does not have is ignored, so a 720p capture cannot be inflated to 4K to match a sequence — that is a job for the scaling in the edit, where at least it is reversible.

Browser-recorded WebM files carry Opus almost without exception, and the MOV written here carries AAC. As with the picture, that is a decode and a re-encode rather than a copy, so there is a second generation of lossy compression on the sound. For dialogue and screen-capture narration it is inaudible; for music it is measurable.

Every audio track the browser can decode survives, in the order the WebM held them. A recording with a separate microphone track and a system-audio track — which some capture tools produce — arrives with both, because the QuickTime container places no practical limit on how many it can carry, and they land on the timeline as separate channels rather than as one mix.

VP9 in WebM can carry transparency, and it is one of the genuinely good reasons to use the format: a lower-third or an animated logo delivered on the web as a transparent WebM composites straight over a page. H.264 has no alpha channel, so that information has nowhere to go.

The conversion does not fail; it produces an opaque video, and the transparency is simply gone. For alpha inside an editor the working formats are ProRes 4444 in a MOV or a PNG sequence, and neither can be produced by a browser. Keep the WebM as the master if the transparency is the asset.

Subtitle tracks and chapter marks are dropped. Matroska-based containers like WebM can hold both, and the engine reads video tracks and audio tracks and nothing else — a subtitle track is not something it declines to convert, it is something it never notices. Captions that came with a recorded meeting will not appear in the MOV, and need to be exported separately from wherever they were made.

Timecode and camera metadata are not carried either, because a browser recording rarely has any to begin with. What you get is a clean file with a duration, its picture and its sound — which is usually exactly what an import dialogue wants, and occasionally a surprise for anyone expecting reel names.

Because every frame is decoded and re-encoded, the conversion takes real time proportional to the length and resolution of the recording rather than to the size of the file. A two-minute clip is quick. An hour of 4K screen capture is a sustained load on your machine, and the tab has to remain open while it runs — closing it cancels the work rather than queueing it somewhere.

The H.264 encoder doing that work belongs to the browser. Chrome, Edge and Safari have one on essentially every current machine; some Firefox installations, particularly on Linux, do not, and the conversion says so up front instead of failing halfway through. There is no software fallback, because an H.264 encoder compiled to WebAssembly is tens of megabytes and roughly an order of magnitude slower than the hardware one sitting idle beside it.

Editing work is full of material that is not supposed to be anywhere. Unreleased product footage, a customer’s dashboard on a recorded call, an internal all-hands, an interview under embargo. The ordinary way to convert a WebM is to upload it to a site nobody has vetted, which is a contractual problem before it is a privacy one.

This conversion runs entirely in the browser, using the same codecs the machine already uses to play video. Nothing carrying the footage is sent anywhere and there is no account. A long capture converts as fast as the hardware allows rather than as fast as an upload allows, which for a multi-gigabyte file is usually the more persuasive argument of the two.