The video is decoded and encoded again into the format you choose, then written into the matching container. MP4 with H.264 plays everywhere and is the safe choice for uploads. WebM with VP9 is smaller at the same quality. Nothing is uploaded — the work happens on your own device, through the same hardware encoder it uses to record.
Every format is tested against your browser before it is offered, and anything it cannot write is shown as unavailable rather than being offered and failing at the end of a long encode. That check matters more here than anywhere else, because codec support depends on the browser, the operating system and sometimes the graphics drivers, so a fixed list would be wrong for a good share of visitors.
Choosing a format
-
MP4 with H.264 for anything you are sending someone:
it plays on every device, every browser and every platform, and it is what upload forms expect. When there is no specific reason to choose otherwise, this is the answer.
-
WebM with VP9 for the web, and for sound on Firefox or Linux:
it is meaningfully smaller at the same quality. It is also the only way to produce a file with audio in Firefox or on desktop Linux, because those cannot encode the AAC that MP4 requires — WebM uses Opus instead, which they can.
-
Converting does not restore quality:
each pass decodes what is there and encodes it again, so artefacts already in the file are preserved rather than removed. Convert once, from the best source you have.
-
Some formats cannot be read at all:
MKV, AVI and ProRes will not open, because browsers cannot decode them. That is a limit on the input rather than the output, and it applies to every video tool here.
Why a format can appear greyed out
Rather than offering a fixed list of outputs, the [msm_tool slug="video-converter"] tests each format against the browser it is running in before offering it, because codec support depends on the browser, the operating system and sometimes the graphics drivers underneath both. A format the browser cannot actually write is shown as unavailable up front, rather than being offered and failing only after a long encode has already run.
MP4 or WebM, and when each is the right call
MP4 with H.264 is the format every device, browser and upload form expects, which makes it the default answer whenever there is no specific reason to choose otherwise. WebM with VP9 produces a meaningfully smaller file at the same visual quality, worth it for anything destined for a web page rather than an upload form. WebM carries a second advantage that has nothing to do with size: its audio codec is Opus rather than AAC, and Opus is the only route to a video with sound on Firefox or on desktop Linux, neither of which can encode AAC at all.
Converting cannot undo a previous encode
Every pass here decodes whatever is actually in the file and encodes it again from scratch, so any artefacts already baked into the source are preserved rather than cleaned up along the way. Converting is worth doing once, from the best copy available — running a file through repeated conversions adds a fresh generation of encoding loss each time rather than improving anything.
What it cannot even open
MKV, AVI and ProRes files will not load at all, and that has nothing to do with this particular tool: browsers cannot decode those containers, so nothing running in one can read them in the first place. Every video tool on the site shares that same limit on what can come in, regardless of what it is asked to do with the file afterwards.
Why the result can end up larger than the original
A file that was already efficiently encoded has little redundancy left to remove, and re-encoding it spends bits faithfully reproducing the artefacts of that earlier pass rather than shrinking anything. That shows up most with a source that has already been compressed for the web once — converting it again is not guaranteed to make it smaller, and sometimes does the opposite.
When converting is pure loss
If the file already plays where it is headed — the platform accepts the current format, the sound already works on the browser in question — converting it adds a generation of encoding loss for no benefit at all. The reason to convert is a real constraint: a format the destination refuses, or audio that will not encode in the format currently in hand. Absent one of those, the existing file is already the better one to send.