Convert MP4 to WEBM

Re-encode an MP4 into WEBM with VP8 or VP9 video and Opus audio, on your own machine. No account, no watermark and no server round trip.

🌐 Español

Drop your file here (.mp4)

🔒 Private by design: your files are processed locally in your browser and never uploaded to any server.

Written and maintained by Last updated

No stream copy exists between these two containers

Plenty of format conversions on this site are close to free, because the container changes and the compressed streams inside it are copied over untouched. This is not one of them, and it never can be.

WEBM is a deliberately narrow profile of the Matroska container. It admits VP8, VP9 and AV1 for video, and Vorbis or Opus for audio, and that is the entire list. A typical MP4 carries H.264 and AAC, neither of which is on it. So there is nothing to copy: every frame has to be decoded back to pixels and encoded again by a different codec, and every sample of audio does the same. That single fact sets the tone for everything else on this page, from how long it takes to what the two settings really do.

Reading the VP8 arguments, and the ceiling hiding in them

Choose the default and the video half of the command is this:

-c:v libvpx -deadline realtime -cpu-used 5 -crf 10 -b:v 1M

The last two arguments together are libvpx’s constrained quality mode. The CRF sets a quality target and the bitrate acts as an upper bound, so the encoder aims for the quality but is not allowed to exceed the budget. A CRF of 10 is a very high target, which means that on anything detailed it is the one megabit ceiling that decides the result rather than the quality figure.

That is what makes the VP8 path predictable. Video is capped at one megabit per second and audio is fixed at 128 kilobits, so the budget works out to an upper bound of roughly 8.5 MB per minute of running time regardless of what you feed it. A talking head or a slide deck recording will look fine inside that budget. A handheld clip of moving water will not, and it is the ceiling, not the codec, doing the damage.

The other two arguments are about speed. The realtime deadline and a high processor setting tell libvpx to take its fastest decisions at every fork, which matters enormously here because the engine runs on a single thread inside the tab.

VP9 runs uncapped, which changes the size question

Switch to VP9 and the arguments become:

-c:v libvpx-vp9 -deadline good -cpu-used 2 -b:v 0 -crf 32

A bitrate of zero paired with a CRF is the opposite arrangement: constant quality with no ceiling whatsoever. The encoder spends whatever each scene needs to hold a CRF of 32 and the file lands where it lands. It also uses a much more careful deadline and a lower processor setting, so it thinks harder about every block.

The upshot is that the dropdown’s shorthand of “smaller file, slower” is reliably true about the second half and only usually true about the first. Codec for codec, at matched quality, VP9 does beat VP8 comfortably. But these two settings are not matched: one has a hard budget and the other has none. For a simple screen recording VP9 will be dramatically smaller. For a high motion 1080p clip, VP9 may well produce the larger file, and the larger file will be the one that actually looks like the source.

“Slower”, meanwhile, is unambiguous. VP9 is a substantially heavier codec than VP8 before you account for the more thorough settings, and none of it is spread across cores.

Deciding between the two before you start the clock

  1. Drop your MP4 on the box, or click Choose a file. Only .mp4 is accepted here, and any other extension is named and refused before work starts.
  2. Set Video codec to VP8 (fast, recommended) for anything long or anything you need soon, or VP9 (smaller file, slower) for a short clip where the look of it matters more than the wait.
  3. Click Convert MP4 to WEBM and watch the percentage. Cancel is there throughout, though it discards the run and empties the box.
  4. Download the WEBM from the link that appears, with the before and after sizes printed just above it.

The honest rule of thumb is about clip length rather than about quality. Under a minute, and VP9 is worth trying because you will get the answer either way in a reasonable time. Over several minutes, start with VP8 and only reach for VP9 if the result disappoints you, because a failed VP9 experiment on a long file costs a lot of waiting for nothing.

Where a WEBM is genuinely the right target

The strong case is embedding. A short clip inside a documentation page, a changelog entry or a product tour is exactly what the format was designed for, it plays natively in current browsers with nothing installed, and it sidesteps the licensing questions that surround the codecs in an MP4 entirely. Projects that have standardised on open formats end to end need a way in from existing MP4 footage, and this is it.

The weak case is anything that has to leave the browser. Video editors, phones, smart televisions and social platforms are all far happier with H.264 in an MP4, which is why the reverse trip, WEBM to MP4, exists and gets more use. If your only goal is a smaller file that still plays everywhere, Compress Video re-encodes an MP4 with x264 quality presets and leaves it as an MP4, which is usually the better answer to that question than changing container at all. For inputs other than MP4, the general video converter accepts a much wider list and can still target WEBM, and it does so by importing this page’s own argument builder rather than reimplementing it, so the encoder settings it uses are the ones described above.

Whichever way you go, a re-encode is a one way door, and it is worth understanding what it costs before you throw away the original. The guide on why re-encoding loses quality covers which edits are free and which are not.

Frequently asked questions

The dropdown calls VP9 the smaller option, but my VP9 file came out bigger. How?

The two settings are aiming at different things. VP8 here runs in constrained quality mode with a one megabit per second ceiling, so a busy 1080p clip is squeezed down to fit that budget however detailed it is. VP9 runs in constant quality mode with no ceiling at all, so it spends whatever the picture needs to hit its quality target. On simple footage VP9 lands well under the VP8 result, and on high motion material it can overshoot it while looking considerably better.

My screen recording is 1366 by 769 and the WEBM came back one pixel shorter. Why?

Both VP8 and VP9 need even pixel dimensions for the color subsampling they use, and window captures and cropped exports very often produce an odd number. Rather than fail, the tool rounds each dimension down to the nearest even number before encoding, so an odd height loses its last row and an odd width loses its last column. One pixel off the bottom edge of a screen capture is not usually something anyone notices, but it is a real, permanent crop.

Is there any way to get a WEBM out of this without re-encoding the video?

There is not, and no tool anywhere can offer one. WEBM is a restricted profile that only admits its own family of video and audio codecs, and the H.264 and AAC streams inside a typical MP4 are not among them. So unlike a container swap such as MKV to MP4, where the streams can often be copied across untouched, every conversion here is a full decode and re-encode of every frame. That is also why it takes real time.

I pressed Cancel and now the next attempt is slow to start again. Is that expected?

Yes. Cancelling stops work already running inside the WebAssembly engine by tearing the whole engine down, which is the only reliable way to interrupt it, and the drop zone is emptied at the same time. The consequence is that the next conversion has to fetch and start the engine again before it can encode anything. Letting a job run to the end and using Process another keeps it warm.

What happens to the audio track, and what if the video has none?

The audio is always re-encoded to Opus at 128 kbps, since that is WEBM's own audio codec and the AAC in your MP4 cannot travel across. It is a second lossy pass over an already lossy track, so a soundtrack that started life at 96 kbps does not improve by being given 128. A video with no audio stream at all converts perfectly well, since there is simply nothing for that part of the command to act on.

My converted file came back playable but obviously truncated. Why did it not just fail?

This page uses the permissive runner rather than the strict one, meaning it does not check FFmpeg's exit code before reading the output back. If a run ends badly but has already written some bytes, those bytes are handed to you as a download instead of being discarded. When nothing was written at all the read itself fails and the panel shows its single generic error line. A short download after a long encode is worth playing all the way through before you rely on it.

Related tools