WebM to MP4 Converter

What WebM and MP4 actually are

Both are containers: boxes holding a compressed video stream, a compressed audio stream and the timing that keeps them together. The box is not the picture. What decides whether a file plays is the codec inside it, and this is the one common conversion where the box and the contents both have to change.

WebM is a deliberately narrow format. It is a restricted profile of Matroska, built for the open web, and it is only allowed to carry VP8 or VP9 video (AV1 in practice too) with Vorbis or Opus audio. MP4 is the ISO base media file format, and the codecs the world built around it are H.264, H.265 and AAC. The two lists barely overlap, which is why a WebM plays perfectly in Chrome and is refused by QuickTime Player, iMovie, most TVs and most phone photo libraries.

Why this one is a real re-encode

Most conversions on this site are not conversions at all. When the codec in your file is already legal in the container you want, the streams are copied across untouched in seconds and the picture is unchanged. That is what happens with MOV to MP4 and usually with MKV to MP4, and the guide on converting without losing quality explains it in full.

WebM cannot work that way. VP9 does have a documented mapping into MP4, but almost nothing outside a browser will decode a VP9 track out of an MP4 file, so producing one would hand you a file that fails in exactly the places you are converting for. So every frame is decoded and re-encoded with x264, and Opus or Vorbis audio is re-encoded to AAC. That is a generation of quality lost. It is unavoidable here, and we are not going to call it lossless.

One exception is worth knowing. If your WebM holds AV1 video, as some downloaded web video does, AV1 is legal in MP4, so the video stream is copied byte for byte and only the audio is re-encoded — the readout tells you which case you are in before you press Convert. An AV1 MP4 still needs an AV1 decoder at the other end, so if the goal is an older TV, phone or editor, set the codec to H.264 in the advanced options and take the re-encode deliberately.

Which quality setting to pick

Because this is a real encode, the quality control matters more here than anywhere else on the site. The three presets are constant-quality settings, CRF 28, 23 and 20, not fixed bitrates: the encoder spends bits where the picture needs them, so a static screen recording comes out small, a handheld clip of moving leaves comes out large, and both look consistent.

• High (CRF 20) for anything you will edit, re-upload or convert again. Each re-encode compounds, so start close to the source.
• Medium (CRF 23) for normal viewing and sharing. This is the sensible default.
• Low (CRF 28) only when a size ceiling is the point, such as a chat app or an email attachment.

Expect a surprise: the MP4 is often larger than the WebM you started with. VP9 compresses more efficiently than H.264, so buying compatibility costs you bytes. That is the trade, not a fault. To hit a size instead of a quality, drop the resolution — a 1440p screen recording is fine at 1080p — or switch rate control to the app's ladder of 1, 2.5 and 5 Mb/s in the advanced options. Leave the frame rate alone unless you have a reason; halving it saves less than people expect and looks worse than a lower CRF.

Screen recordings, and why yours misbehaves

Most WebM files people want as MP4 were written by a browser as the recording happened — a screen recorder, a meeting tool, a web app capturing your tab. Files written that way often lack a proper duration in the header, so the player shows an unknown length, the scrubber does nothing, and the clip will not trim cleanly in an editor. Nothing is corrupt; the header was simply never finalised.

Re-encoding fixes that as a side effect: the output is written from scratch with real timestamps and a real duration. If the recording also drifts out of sync in a timeline — fine at the start, seconds off by the end — that is a separate problem called variable frame rate, and the guide on converting VFR to constant frame rate is worth reading before you edit, because setting a fixed frame rate here is the repair.

What gets lost

Only the first video stream and the first audio stream survive. Subtitle tracks are dropped, additional audio tracks are dropped, and chapters and container tags do not cross over. The tool counts these in your file and warns you before it starts rather than after. Alpha is the one that catches people out: a transparent VP9 overlay or animation loses its transparency, because H.264 in an MP4 has nowhere to store it, and the background becomes solid.

The honest limits of a browser tab

The build here is single-threaded, so a re-encode is not fast. As an order of magnitude on a normal laptop, a 720p clip converts at roughly the speed of the clip itself and 1080p is slower than that, with VP9 decoding adding to the bill. Your machine, your browser and how busy the picture is all move that number, so treat the on-screen estimate as a guide rather than a promise.

Files over 2 GB are refused outright, because a 32-bit WebAssembly heap cannot address them, and above roughly 300 MB you get a warning: the conversion wants about three times the file size in free memory. Screen recordings reach those numbers faster than people expect. If you are on a phone, use a computer for this one — mobile browsers are the worst case for memory and worker threads, and our phone app is not the fallback here, because it reads MP4, MOV, MKV, AVI and 3GP and does not accept WebM at all. A desktop browser is genuinely the right tool for a WebM.

Why people end up on this page

The pattern is nearly always the same: the file was produced by the web and now has to leave it. A tab recording that has to go into a deck, which is covered by the guide on video that will not play in PowerPoint. A clip saved from a website that a phone refuses to add to its camera roll. Footage an editor rejects for the same reason it rejects Matroska — Premiere refusing MKV — since WebM is a Matroska profile with a different extension. Or a file bound for Instagram, WhatsApp or a TV, none of which want VP9.

In every case the target is the same: H.264 video with AAC audio in an MP4, the most widely playable combination there is. If you are not sure what is inside your file, the same reader runs on the check your video's codec page and answers it in a second. Files that turn out to be H.265 rather than VP9 belong on the HEVC to H.264 converter instead.