Why a WebM recording needs more than a format change
WebM is what browsers save when they record: screen recorders that run in a tab, Loom and Google Meet downloads, and anything made with the browser's own recorder. Inside is usually VP8 or VP9 video with Opus sound. Most phones, PowerPoint, video editors and upload forms expect MP4 with H.264 video and AAC sound, so the picture and the sound both have to be encoded again. That part is routine. The trouble is in how browsers write the file.
A browser records while it happens and never goes back to the start of the file, so three things are often wrong in a WebM recording:
- No length. The file does not say how long it is. Chrome's own player reports the length as infinite and cannot jump ahead.
- Frames with no length. Chrome's recorder stores the first frame of every recorded chunk, usually once a second, with a length of zero.
- A full-range colour label. The recording says its colours use the full 0 to 255 scale, and the frames the browser decodes from it lose that label.
Each of these breaks something in a plain conversion, and none of them shows an error. This tool works around all three and prints what it found, so you can see the result instead of trusting it.
What we measured
We recorded test videos with Chrome's own recorder, the same way browser-based screen recorders do, and converted them in Chrome on a Windows PC on 11 October 2026. Each MP4 was read back with a separate decoder (FFmpeg, through PyAV), not with this tool. For comparison, we also ran the same files through the ready-made conversion of the video library this tool uses, which is what a plain browser converter does.
| Recording | Plain conversion | This tool |
|---|---|---|
| 8 s screen recording, 640 × 360, VP9 + Opus, no length in the file | 230 of 240 frames; the last frame missing | 240 of 240 frames; length 8.06 s, seeks |
| Same recording: colours as Chrome shows them | Visibly darker: the dark blue background went from an average red value of 19.7 to 5.0 (25.8 dB) | Matches the original (44 to 45 dB) |
| 6 s recording of a window, 853 × 481 (odd size) | MP4 with the sound and no picture | 854 × 482, 136 of 136 frames |
| 15 s, 1920 × 1080 screen recording, 475 KB | – | 589 KB, 400 of 400 frames, 46.8 dB, about 16 s to convert |
| H.264 + AAC video in an MKV file | – | Copied without re-encoding, 90 of 90 frames |
The decibel figures compare each frame of the MP4 with the same frame of the recording; above about 40 dB the difference is very hard to see. The MP4 is a little bigger than the WebM because H.264 needs more data than VP9 for the same picture. We tried doubling the bit rate for sharper text: the 1080p file grew by 0.06% and the picture was no better, because the encoder already had all it needed. So there is one quality setting, not two.
The missing length
A WebM recorded in a browser has its length missing from the file's header. Players then show
--:-- or an endless timeline, and skipping ahead either does nothing or starts from the
beginning. The video itself is all there. The MP4 this tool writes gets the real length and an index of where
each second starts: in our test the MP4 reported 8.06 seconds and jumped straight to the 5-second mark.
The same problem affects the sound; if you only need that, WebM to MP3 fixes the length
of the audio without touching the picture.
The frames a plain re-encode drops
Chrome's recorder hands over the recording in chunks, usually one per second, and stores the first frame of each chunk with a length of zero. Players do not mind: they show each frame until the next one arrives. A re-encode that trusts the stored lengths does mind. In our 8-second recording it dropped 10 of 240 frames, one per second, including the final frame. This tool gives every frame the time until the next one instead, and the result shows two numbers side by side: frames in the recording, frames in the MP4.
Odd sizes and dark colours
H.264 only accepts even widths and heights, and a recording of a single window or a browser tab is often an odd size. In our 853 × 481 test, the plain conversion dropped the picture without a word and wrote an MP4 with sound only. Here the picture is stretched by one pixel in each direction, too little to see, and the result says so. Chrome's default decoder also failed on that odd-sized VP9 recording; the tool notices and decodes it with the browser's software decoder instead.
The colour problem is quieter. Browser recordings are labelled as full-range colour, and the frames the browser decodes from them lose the label, so a converter that draws them as they come stretches the colour scale a second time. Dark backgrounds turn almost black and the whole picture looks harsher. This tool copies each frame with the correct label before encoding it, which is why its result matches what Chrome shows for the original.
Limits
- The MP4 is built in your browser's memory. A long 1080p recording is fine on a desktop; an hour of 4K may be too much for a phone.
- In our test, a 1080p recording took about as long to convert as it takes to play (16 s for 15 s), more on a slow computer. The page has to stay open.
- Converting does not make the file smaller. To fit an upload or email limit, use Compress Video afterwards; to cut the start or end, Trim Video.
Recorded on an iPhone instead? Those are MOV files, and MOV to MP4 converts them without re-encoding. Everything on this page runs in your browser: the recording is never uploaded.