What is a remux and why is it not possible here?

A remux is the operation of copying video and audio data from one container to another without touching it at all; because the compression algorithm never runs it is fast and there is no quality loss. But for a remux to work, the target container has to recognise the codec in the source. WEBM accepts only the VP8, VP9 and AV1 video codecs; MOV files, meanwhile, usually carry H.264 or ProRes. Since those two lists do not intersect at all, the data cannot be carried over as it is and re-encoding becomes mandatory.

What exactly am I losing in re-encoding?

Lossy compression shrinks the file by discarding the details the human eye is least likely to notice. If the source MOV was already compressed with H.264, some detail has long since been thrown away; when you decode that picture and recompress it with VP9, a second round of culling takes place. The places where the loss is most visible are fast-moving scenes, wide areas of flat colour and dark passages. At a good quality setting that loss is indistinguishable to the eye in most scenes, but technically it is there and cannot be undone.

Is the situation different with a MOV containing ProRes?

You are somewhat better off in terms of loss, because ProRes applies very little compression and the amount of detail already thrown away in the source is small; the only culling laid on top is the one from the WEBM encode. In terms of processing time, however, the situation is more demanding, because ProRes files are enormous and the amount of data to read is very large. Re-encoding itself is still unavoidable, too, because WEBM cannot carry ProRes in any form.

Is there a way to speed the operation up?

The most effective route is to pick VP9 instead of AV1; AV1 compresses more efficiently but encodes markedly more slowly. The second route is to reduce the resolution; if you do not need 4K for web delivery, a lower resolution cuts both encoding time and file size considerably. Trimming the unnecessary sections out of the video before converting also shortens the time by reducing the number of frames to be processed.

Why Does MOV to WEBM Conversion Always Require Re-encoding?

The same operation, very different durations

When you convert a MOV file to MP4, the operation often finishes surprisingly quickly. Convert the same MOV file to WEBM and you wait minutes. Same file, same duration, same resolution. Where does the difference come from?

The answer is hidden in the most fundamental distinction in digital video: the difference between the container and the codec. Once you grasp that distinction, you become able to predict which conversion will be fast and which slow without even looking at the file.

Container and codec: two separate layers

Think of a video file as having two layers.

The container is the outer layer — the box the file comes in. It holds the video track, the audio track, subtitles if there are any, the metadata and the synchronisation information all together. MOV, MP4, WEBM and MKV are containers. A container does not compress the picture and does not determine quality.

The codec is the inner layer — it determines which algorithm the picture and sound are compressed with. H.264, H.265, ProRes, VP9 and AV1 are video codecs. AAC, MP3, Opus, Vorbis and PCM are audio codecs. This layer is what determines the size and the visual quality of your file.

The critical point: not every container can carry every codec. Each container has a list of codecs it accepts, and what determines whether a conversion will be fast or slow is whether those lists intersect.

If there is an intersection: remux

If the codec in the source file also appears on the list the target container accepts, something excellent happens. You never need to decode the picture at all. The video and audio data are taken out of the old box and put into the new one exactly as they are. This operation is called a remux.

A remux brings two big benefits. First, the quality loss is zero — the data stays identical bit for bit and no detail is discarded. Second, it is fast — the compression algorithm never runs, only data is copied, so what really sets the time is the speed of your disk and your connection.

That is exactly what happens when you convert a MOV containing H.264 into an MP4. Because the MP4 container already accepts H.264, the data is carried across and the job is done. That is the reason that particular conversion is fast.

If there is no intersection: re-encoding

The list of codecs WEBM accepts is quite narrow, and that is a design choice. WEBM was designed as an open web format free of patent burden; it therefore carries only open codecs:

Video: VP8, VP9, AV1
Audio: Vorbis, Opus

Now let us look at the typical contents of MOV files:

Video: H.264 (iPhone, screen recordings, most cameras) or ProRes (professional editing)
Audio: AAC or uncompressed PCM

There is not a single element in common between the two lists. H.264 cannot go into WEBM. ProRes cannot go in at all. AAC is not on WEBM's audio list either.

In this situation only one route remains: transcoding, in other words re-encoding. The process works like this. Every frame of the source video is passed through an H.264 decoder and unpacked into raw pixels. Those raw frames are then handed to a VP9 or AV1 encoder and recompressed from scratch. The same happens on the audio side: the AAC is decoded and re-encoded as Opus or Vorbis.

Two honest consequences of this

First: the operation is slow. Every frame in the video has to pass through two separate algorithms. VP9 and AV1 encoders in particular perform intensive computation — efficient compression is born precisely out of that computation. On a long, high-resolution file, an operation running for minutes is not a defect but expected behaviour. When you pick AV1, that time lengthens markedly compared with VP9.

Second: you lose some quality. Lossy compression shrinks the file by discarding the information the human eye is least likely to notice. If the source MOV was already compressed with H.264, some detail has long since been thrown away. When you decode that picture and recompress it with VP9, a second round of culling is applied. This is a loss laid on top of a loss, and it cannot be undone.

At a good quality setting that loss is not noticeable to the naked eye in most scenes. But in some places it does become visible: blurring in fast-moving scenes, colour banding in wide areas of flat colour (a sky, for instance), block artefacts in dark scenes. If you are seeing these, your quality setting is too stingy.

Practical consequences

Once you understand this mechanism, three behaviours become automatically correct.

Keep the chain short. Every re-encode adds a fresh loss. Rather than converting the video to MP4 first, then to WEBM, then to something else again, go straight from source to target. When you do a MOV to WEBM conversion, let your source be the original file.

Finish your editing first. Operations such as trimming, colour correction and burning in subtitles mean another re-encode. Do them before the conversion, while you are still working with the source file.

Never delete the original. The WEBM output is a version that has lost information from the source. If you need a different format tomorrow, you should start from the original MOV, not from the WEBM.

Which conversion is fast and which is slow: a practical way to predict

Once you grasp this logic, you can roughly estimate how long a conversion will take before you even start it. All you have to do is ask two questions.

First question: which codec is inside the source file? MOV files usually carry H.264; professional camera and edit exports contain ProRes. The file size gives you a clue — if a video of a few minutes takes up gigabytes, there is a lightly compressed codec such as ProRes inside.

Second question: does the target container accept that codec? MP4 accepts H.264, so going from a MOV containing H.264 to MP4 is a remux and finishes quickly. WEBM, on the other hand, accepts neither H.264 nor ProRes, so every road leading there passes through re-encoding.

Ask those two questions and the answer emerges on its own. If there is an intersection, fast and lossless; if there is not, slow and somewhat lossy. The rule is that simple, and it works the same way for other containers such as MKV and AVI.

One caveat: with a MOV containing ProRes you are actually a little better off in terms of loss, because ProRes applies very little compression and the amount of detail already thrown away in the source is small. So the only culling laid on top is the one from the WEBM encode. In return, the processing time gets even longer, because the amount of data to be read is enormous.

In summary

The fact that MOV to WEBM conversion is slow and lossy is not a matter of a missing tool or a wrong setting; it is the direct consequence of the codec lists accepted by the two containers not intersecting at all. WEBM is a narrow container built on open codecs, while MOV is a container carrying entirely different codecs such as H.264 and ProRes. With no common denominator, the picture necessarily has to be decoded and recompressed — which means time and some quality. Whether that price is worth paying depends on your goal: if you are going to publish the video on your own website, WEBM's browser compatibility and efficient compression cover the cost. But if you are only going to send the file to someone, MP4 — where changing the container is free — is a far smarter target.