Convert a video
An extension names the box. What matters is usually the thing inside it.
How it works
MP4, MOV, MKV, WEBM and AVI are boxes. Each one is an index: a table saying that a video track begins at this byte offset, that an audio track is interleaved with it, that the whole thing runs for so many seconds. None of them states how a single frame was compressed. The codec does that, and the four in general use are H.264, HEVC, VP9, AV1.
One codec can sit in several boxes, so a MOV recorded on an iPhone and an MP4 out of a mirrorless camera frequently hold the identical encoding at the same profile and level. Changing one into the other is rewriting an index. The compressed packets are copied across untouched, no frame is decoded, and the footage in the output is the footage that was in the input.
When only the wrapper changes
This tool reads the file before it does anything to it. Where the codec already belongs in the container you asked for, the shared pipeline copies packets instead of decoding them, and the work is bounded by how fast the source can be read. Measured in this repository on a ten-second 640×360 H.264 clip in Chrome: a packet copy finished in 139 milliseconds, and re-encoding comparable footage took 605.
The note beside the result names which of the two ran, so a rewrap and a re-encode are told apart by reading rather than by watching the progress bar. Frame size and bitrate are left as the source had them. Altering either forces a decode, and both have tools of their own. MKV, AVI and MPEG transport streams are read on the way in, since somebody holding one of those generally wants precisely this.
The case that is not free
Two things end the copy path. The first is a codec the destination cannot carry. MP4 can legally hold VP9 and a browser will play the result, yet `containerFor` in the shared pipeline maps VP8 and VP9 to WebM and refuses to write either into an MP4, because that combination is rejected by QuickTime, by Premiere and by most phone galleries. A WebM asked to become an MP4 has to be decoded and encoded again as something an MP4 is expected to hold.
The second is the browser. `chooseCodec` asks `canEncodeVideo` about each candidate in turn, H.264 then HEVC then AV1 then VP9 for an MP4 request, and takes the first one the machine accepts. The container then follows the codec rather than the request: ask for MP4 in Firefox, which encodes VP9 and has no H.264 encoder, and the chooser falls through and the download arrives as a WebM. The extension and the result note both say so.
Which pairing opens where
H.264 inside an MP4 plays on close to everything built since about 2010. It is the codec the fixed-function decoders in phones, televisions and laptop silicon were designed around, so playing it costs a dedicated block rather than a CPU core and a battery. Nothing else here has that reach, and it is why the pipeline tries H.264 first for an MP4 even though two of the alternatives compress better.
VP9 inside a WebM is what the web serves. Every current desktop browser decodes it, Safari has since version 14, and VP9 is royalty-free, which is the practical reason Firefox ships an encoder for it and none for H.264. Away from a browser the support thins out fast, and that is what the container rule above is defending against.
AV1 is materially smaller at matched quality, around 30% under VP9 by the Alliance for Open Media's own figures, and a decade of hardware cannot decode it at all. It is reached here only when a browser offers no earlier encoder, because a file that is smaller and unplayable has not finished the errand.
Where the file goes
Nowhere. The video is read by the page, converted in a Web Worker on your own machine, and handed back as a download, with no server in the path and no account to create. Sources up to 2 GB are accepted, though the pipeline projects peak memory before starting and refuses with the arithmetic where a job would not fit inside the roughly 250 MB a browser tab has to work in.
Questions
Is the video uploaded to convert it?
No. Keep the Network tab of developer tools open and convert something. What appears is same-origin traffic for this page's own code and the encoder module it needs, and nothing carrying the video, because there is nowhere for it to be sent. A file you never hand over cannot be retained, logged or scanned by anybody.
I picked MP4 and a WebM came out. What happened?
Your browser has no encoder for any codec an MP4 carries. Firefox is the usual case: it encodes VP9 and not H.264, so the codec search falls through to VP9, and VP9 belongs in a WebM. The alternative would be an MP4 with VP9 inside it, which plays in browsers and is refused by QuickTime, Premiere and most phone galleries. Chrome, Edge and Safari all produce the MP4.
Does converting cost any quality?
Only when the picture had to be encoded again, and the result note says whether it was. A codec that already suits the destination is copied packet for packet, which is lossless and takes about as long as reading the file. A codec the destination cannot carry is decoded and compressed a second time, and a second lossy pass always discards detail the first one left behind.
Which of the two should I choose?
MP4 for anything going to another person, another program or a phone, because H.264 in an MP4 is the combination with no compatibility argument attached. WebM for a page you control, where the audience is a browser and nothing else has to open the file. Neither choice changes how the video looks beyond what an unavoidable re-encode costs.