MP4 or WebM: Converting Video in the Browser

Converting a video used to mean uploading it somewhere and waiting, or installing something. The video format converter does it in the tab you already have open, using ffmpeg compiled to WebAssembly, and moves between MP4 with H.264 and WebM with VP8.

A correction, 2026-09-11. This article previously described a third target, WebM with VP9, and named it the default. The converter offered it and it never worked: the WebAssembly ffmpeg build this site ships cannot encode VP9. Seven encoder settings were measured against it in a real browser, each on a fresh core, and every one crashed after the first frame while a VP8 control succeeded on the same clip. The tool's only browser test converted to MP4, which is why the broken default survived. VP9 has been withdrawn rather than quietly pointed at the VP8 encoder, because a converter that names one codec and returns another is worse than one that offers fewer.

Two targets is a short list, and each one exists for a reason.

What the two are for

MP4 with H.264 is the compatibility answer. If you do not know where the file is going, or it is going somewhere you do not control, this is the safe choice. Hardware decoders for H.264 are in essentially every phone, television, laptop and editing application made in the last fifteen years. It is not the most efficient codec available and that is not the point.

WebM with VP8 is the open-format answer. It is royalty free and it plays in browsers and in most editing software that accepts WebM at all, including older versions. It is less efficient than H.264 at the same quality, so it is usually the larger file of the two , so you choose it for the format rather than for the size.

The practical decision is nearly always between the first two: is this file for a platform and an audience I control, or is it going to arrive somewhere unknown.

Conversion is re-encoding, and re-encoding costs quality

This is the part that surprises people who think of format conversion as repackaging.

Changing codec means decoding every frame and encoding it again. The new encoder does not know what the original looked like before the first encoder threw parts of it away. It only sees the result, including the artefacts, and it spends bits preserving those faithfully.

Two consequences worth planning around:

Convert from the best source you have. Going camera original to VP8 gives a better result than going camera original to H.264 to VP8, even if the intermediate looked fine.

Do not chain conversions. Every pass compounds. If you need both an MP4 and a WebM, produce each from the same source rather than producing one and converting it into the other.

There is no lossless option in this set. Both are lossy codecs, so there is no equivalent of the PNG to lossless WebP move that exists for images.

Time is real

Video encoding is genuinely expensive work and a browser tab is doing it on your machine. A long clip, a high resolution, or a laptop already busy will all show up as time.

VP8 in particular is not fast in this build. That is the cost of running the encoder in WebAssembly rather than natively, and it is the wrong trade when you need the file in the next two minutes.

Nothing about this is hidden by a queue. There is no server absorbing the cost and no progress bar that is actually waiting for somebody else's hardware, which means the duration you see is the honest cost of the encode.

The encoder is the same everywhere

The converter does not use the browser's own codecs. It ships its own copy of ffmpeg, compiled to WebAssembly, and runs it in a worker.

That is worth knowing because it inverts what you might expect. Browser codec support varies by browser, platform and even by how the machine was built, so a tool built on the browser's encoders offers a different menu to different people. This one carries its encoders with it, so all three targets are available to everyone, and a conversion that works on your machine works on somebody else's.

The cost of carrying them is the download and the speed: a WebAssembly encoder is slower than a hardware one, which is most of why a long clip takes real time.

Audio comes along

A conversion that silently dropped the audio track would be a disaster discovered at the worst possible moment. Check it anyway on anything important, because that is the single fastest thing to verify and the most annoying to discover late. Play the converted file, with sound, before you rely on it.

Nothing is uploaded

The file is decoded and re-encoded on your device. It is not sent anywhere, there is no third-party transcoder in the path, and no copy sits in a queue.

For video this matters more than for images, simply because of what video tends to contain. Unreleased footage, client work under embargo, recordings of people who consented to one use and not to a copy on somebody's server. The way to keep those off a server is not to have a server.

When you should not use this tool

When the real goal is a smaller file. Use the compressor. Converting for size is guesswork; compressing lets you tune quality directly.

When you do not know which format wins. Use the format comparison tool, which encodes the same clip three ways so you can compare actual sizes instead of reasoning about codecs in the abstract.

When you only need to fix orientation. Use the rotate tool. Converting to fix a sideways video re-encodes the whole thing to solve a problem that has its own dedicated fix.

A short method

1. Start from the best source you have, not from an export of an export.
2. Choose H.264 in MP4 when the destination is unknown or out of your control.
3. Choose VP8 in WebM when you specifically need an open format, accepting a larger file.
4. Produce each format from the source, never from the other format.
5. Expect real encode time, and expect it to scale with resolution and length.
6. Play the result with sound before you ship it.