VP8, VP9 and the codec wall outside the browser
WEBM is not really a video format, it is a container: a deliberately trimmed subset of Matroska that Google standardised so the web would have a royalty-free way to ship video. What matters is what goes inside it, and by convention that is VP8 or VP9 video with Opus or Vorbis audio. Every one of those codecs was designed to avoid patent licensing, which is precisely why browsers adopted them and why very little else did.
The result is a format with a strange support curve. Chrome, Firefox and Edge decode WEBM flawlessly. A hardware decoder in a television, a set-top box, a car head unit or an older iPhone has H.264 silicon and frequently no VP9 path at all. Editing software is the worst case: iMovie will not import it, PowerPoint ignores it, and several versions of Premiere Pro and DaVinci Resolve either reject the file or open it as an audio-only clip, because they can parse the container and then find a video track they cannot touch.
So a browser recorder hands you a file that plays perfectly in the tab that produced it and nowhere you actually need it. Google Meet recordings, Discord clips, Loom exports, and anything captured through the MediaRecorder API (including this site’s own Screen Recorder, which can only write WEBM because that is all browsers expose) all land in the same trap.
H.264 in MP4 is the opposite extreme. It is patent-encumbered, which is the reason the web went looking for an alternative in the first place, and it is also the most widely decodable video format that exists. Converting is the pragmatic move, not the ideologically pure one.
The exact FFmpeg command behind the button
There is no server involved, so nothing is hidden. The conversion runs FFmpeg compiled to WebAssembly inside the page, and the arguments it builds are short enough to read in full:
-vf scale=trunc(iw/2)*2:trunc(ih/2)*2
-c:v libx264 -crf 23 -preset fast -pix_fmt yuv420p
-c:a aac -b:a 128k
-movflags +faststartMost of those flags exist because of a specific thing that goes wrong with WEBM sources. libx264 is the H.264 encoder, the part that makes the file play everywhere. yuv420p is forced because VP8 and VP9 sources can arrive with 4:4:4 chroma or an alpha channel, and a player handed either of those in an MP4 tends to show a green frame or refuse the file. The scale filter rounds width and height down to the nearest even number, since H.264 works in macroblocks that require even dimensions and a browser recorder will happily capture a 1437 by 903 window. And aac is there because MP4 players do not decode Opus or Vorbis, so skipping the audio re-encode would give you silent video.
+faststart moves the moov atom to the front of the finished file. That costs one extra pass over the output and it is the difference between an MP4 that starts playing while it downloads and one that only plays after the final byte lands.
Picking a quality level for a screen recording
The three quality choices map onto a single number, x264’s constant rate factor: 18 for High quality, 23 for Balanced, 28 for Smaller file. CRF is inverted, so a lower number spends more bits and produces a larger file. Balanced sits at x264’s own default and is the right answer for nearly every recording.
The case for 18 is screen content with small type in it: a code walkthrough, a spreadsheet, a design review at full resolution. Text is unforgiving, because H.264 concentrates its bits on the parts of the frame that move, and a static block of 11 pixel type is where ringing shows up. The case for 28 is a clip you are pasting into a chat window, where clearing an upload limit matters more than crisp edges.
If you have a target file size rather than a target quality, Compress Video is the better tool. It aims at a size directly instead of asking you to guess at a CRF.
Converting your file, step by step
- Drop the
.webminto the box above, or click to pick it from disk. - Leave Quality on Balanced (recommended) unless the recording has fine text you need to stay sharp.
- Click Convert WEBM to MP4 and watch the progress bar. The output keeps your original file name with the extension swapped.
Screen recordings are the worst possible thing to hand a stranger
Most files people convert are unremarkable. Screen recordings are not. A capture of your own desktop shows the subject lines in your inbox, the internal dashboard you were demoing, a customer’s name in a CRM, the Slack notification that slid in halfway through. Uploading that to a converter you found on the second page of search results means a copy of all of it resting on someone else’s disk under a retention policy you will never read.
Nothing here is uploaded, so that question never arises. The only network request in the whole operation is the one-time fetch of the FFmpeg core from unpkg the first time you convert something. Your video is read from disk into the tab’s memory and written straight back to your downloads folder.
Troubleshooting a WEBM that will not convert
The progress bar crawls. One core is doing the encoding, on purpose, for the ad-iframe reason described above. Leave the tab open in the background; closing it stops the work, and the Cancel button terminates the FFmpeg worker outright.
The tab runs out of memory. A very long, high-resolution recording has to fit in the browser’s WebAssembly heap alongside the encoder itself. If it fails, cut it down with Trim Video first and convert only the part you need.
The transparent background vanished. VP9 can hold alpha, H.264 in MP4 cannot, and there is no setting that changes that. Keep the WEBM if transparency is the whole point.
Nothing happens at all. A file whose extension says .webm but whose contents are something else fails during demuxing. If you renamed it by hand at some point, try the general video converter instead, which does not assume what the container holds.