Convert MP4 to WebM online

How to convert MP4 to WebM in your browser

1. 01

   Open the file

   Drag your MP4 onto the drop zone above, or click it and pick the file. If a dragged file appears to do nothing, click the drop zone and choose it instead — the drag handler only accepts files your operating system has labelled as video, and it labels some MP4 files as nothing at all. Either way it is read straight off your disk into the browser tab; nothing is sent anywhere.

2. 02

   Check that WebM is selected

   The Output format control below the timeline is already set to WebM on this page. VP8 encoding is considerably slower than H.264 in WebAssembly, so consider setting Max resolution to 720p on anything long.

3. 03

   Optionally cap the resolution or mute

   Max resolution caps the height at 1080p, 720p or 480p (it never upscales), and Mute audio drops the audio track. Both are optional and both are applied in the same pass as the conversion.

4. 04

   Press Convert video

   With no cuts or speed changes queued, the apply button reads "Convert video". Press it. The first run downloads the ~32 MB FFmpeg engine, which the browser caches for next time.

5. 05

   Download

   When the encode finishes a download link appears with the size of the finished file next to it. Compare it against the original before you delete anything.

Why anyone wants a WebM

Fewer reasons than there used to be, and it is worth being honest about that. WebM was created so the web would have a video format built on royalty-free codecs, and for years it was the way to serve video to Firefox and Chrome without a patent-encumbered H.264 licence. Today every major browser plays H.264 MP4, so "I need WebM for the web" is often not true any more.

The reasons that remain are specific. Chromium-based tools such as Electron apps frequently ship without an H.264 decoder. Some CMSs, wikis and forum software accept only open-codec uploads on principle (Wikimedia Commons is the famous example; it accepts VP8, VP9, AV1 and Theora, so the VP8 this page produces qualifies). And a <video> tag with a WebM source alongside an MP4 source is still a reasonable belt-and-braces choice. If none of those describe you, stick with MP4.

What changes: everything

WebM is a Matroska subset that permits only VP8, VP9 or AV1 video with Vorbis or Opus audio. Your MP4 is almost certainly H.264 with AAC, and neither is allowed in a WebM. So the container changes, the video codec changes and the audio codec changes, and there is no way to do any of it without decoding and re-encoding both streams.

This page writes VP8 with libvpx and Opus audio. VP8 rather than VP9 is a deliberate choice: the VP9 encoder in this WebAssembly build crashes at the speeds that would be usable in a browser tab, and VP8 is stable. The encoder runs with a realtime deadline and a bitrate target of roughly 1 Mbps, which is what makes the speed tolerable. AV1 is not offered.

Quality, size and speed — the honest part

This is the only output on the site that is not H.264, and it is the only one with a real cost. VP8 is a 2010-era codec and, at the roughly 1 Mbps target used here, it is noticeably less efficient than the libx264 encode the other pages use. On low-motion content — a talking head, a screen recording, an animation — the result looks fine. On detailed, fast-moving footage at 1080p it will look softer than the MP4 you started from, because a 1 Mbps budget is simply tight for that. Capping the resolution at 720p gives the same bits fewer pixels to cover, which helps.

Speed is the bigger surprise. VP8 encoding in WebAssembly is considerably slower than H.264, even with the multi-threaded core, and there is no progress-bar trick that changes that. A clip that converts to MP4 in a minute can take several to become a WebM. Trim to what you need first, cap the resolution, and expect to wait. How it works explains why everything is bound by your own CPU.

Why there is no lossless shortcut for this one

For MOV or MKV outputs a command-line remux with -c copy is often the better answer than a re-encode. For WebM it never is, on this site or anywhere else: H.264 and AAC are not permitted in a WebM, so ffmpeg -i in.mp4 -c copy out.webm fails outright. Every MP4 to WebM conversion is a full re-encode of both streams.

If you have FFmpeg installed and quality matters more than time, encode VP9 there instead: ffmpeg -i in.mp4 -c:v libvpx-vp9 -crf 32 -b:v 0 -c:a libopus out.webm produces a considerably better file than VP8 at the same size, at the cost of a much slower encode on a desktop CPU that can afford it.

What stays the same on every conversion here

Nothing is uploaded. The file is read from your disk into the tab, FFmpeg compiled to WebAssembly does the decode and the encode there, and the result is handed back as a download. What does and does not leave your device is spelled out in full. There is no account, no watermark and no size cap other than the memory of the device you are on, since the whole file lives in RAM while it is being worked on.

The first conversion downloads the engine, roughly 32 MB, which the browser caches afterwards. Where SharedArrayBuffer is available the multi-threaded core is used and the encode runs across your CPU cores; otherwise a single-threaded build takes over and the same job takes several times longer. How it works walks through the pipeline, and the FAQ covers the rest.

Questions about converting MP4 to WebM