Convert WebM to MP4 online

How to convert WebM to MP4 in your browser

1. 01

   Open the file

   Drag your WebM 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 WebM 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 MP4 is selected

   The Output format control below the timeline is already set to MP4 on this page. Every modern browser decodes WebM, so the preview and the timeline work. One caveat for browser screen recordings: they often carry no duration in the header, and the editor spends up to four seconds hunting for the real length before the controls appear.

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.

Where WebM files come from

Almost always from a browser. WebM is the format the web's own recording API, MediaRecorder, writes in Chrome, Edge and Firefox, so it is what you get from screen-recording extensions, in-browser webcam recorders, meeting tools that record locally, and the "download" button on a lot of web-based capture services. Discord clips, some Twitch and YouTube download tools and a good deal of saved web video are WebM as well.

Those files play fine in the browser that made them and then run into everything else. older iPhones and iPads will not open WebM (Safari 16 and later can play VP8 and VP9 WebM, but the share sheet and the Photos app still do not accept it), Final Cut and Premiere either refuse it or import it badly, and many upload forms accept only MP4 or MOV. Converting to an H.264 MP4 is the standard fix, and the one file that comes out plays everywhere.

Browser-made WebMs have a second, sneakier problem: because MediaRecorder streams the file out as it records, it often writes no duration and no seek index into the header. The file plays, but the player shows a length of 0:00 or infinity and you cannot scrub. Re-encoding through FFmpeg writes a proper header, so the MP4 that comes out of this page seeks normally.

What changes: WebM and MP4 share no codecs

WebM is a subset of Matroska defined around open codecs only: VP8, VP9 or AV1 video and Vorbis or Opus audio. MP4 is built around H.264, HEVC and AAC. H.264 is not permitted in WebM, and VP8 has no place in MP4 (VP9 and AV1 technically do, but almost nothing plays a VP9 MP4). So in practice this conversion is never a matter of rewrapping — the picture and the sound both have to be decoded and encoded again.

That is what happens here: FFmpeg decodes the VP8 or VP9 stream and the Opus or Vorbis audio, and writes H.264 with libx264 at ultrafast, CRF 28, plus AAC audio, into a fragmented MP4. Frame rate and resolution are preserved unless you set a Max resolution cap.

One thing to check: a browser recording of a shared screen is frequently variable frame rate and can have an odd resolution — 1366×768 minus a browser chrome, say. The output here has regular timing and the same dimensions as the input, both of which editors tend to be happier with than the original.

Quality and size

VP8 and VP9 from MediaRecorder are usually encoded at a modest bitrate to keep up in real time, so the source is already somewhat compressed and CRF 28 H.264 keeps what is there without visible extra loss on screen content. The MP4 may come out larger than the WebM, especially from VP9, because ultrafast does not spend the CPU time that would make H.264 competitive on size. That is the trade for an encoder running in a browser tab rather than on a server, and it is the honest reason to cap resolution if the file is heading over a slow connection.

If what you actually need is a smaller file at the same resolution, that is bitrate compression rather than conversion, and it is not what this tool does. Resizing is the size lever that does exist here.

Why there is no lossless shortcut for this one

With MOV or MKV there is often a way to get an MP4 without re-encoding, by copying the streams into the new container. That does not usefully exist for WebM to MP4, on this site or on the command line, because the two containers' codec sets barely overlap in practice: ffmpeg -i in.webm -c copy out.mp4 fails outright for VP8 and, for VP9, produces an MP4 that almost nothing plays. A re-encode is the correct answer here, not a limitation of this tool.

One detail specific to this direction. The editor does try a lossless stream copy when mute is the only change and the output is MP4, MKV or MOV, and how that turns out depends on which codec your WebM holds. A VP8 WebM cannot be copied into MP4 at all, so the attempt fails and the normal H.264 re-encode takes over automatically — you get the right file either way. A VP9 WebM is the awkward one: the MP4 muxer does accept a VP9 stream, so the copy can succeed and hand you a VP9-in-MP4 file, which is precisely the combination almost nothing plays. If your WebM is VP9 and you want an MP4 that plays everywhere, leave Mute audio off, or set a Max resolution, so the re-encode to H.264 actually runs.

The one case worth knowing about: if you only need the WebM to seek properly and it is staying on the web, ffmpeg -i in.webm -c copy fixed.webm rewrites the header with a duration and cues without touching the streams. That is a WebM-to-WebM repair, not a conversion.

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 WebM to MP4