MP4 vs. WebM: the container is not the codec
An .mp4 or .webm extension names a container, not a quality level. The streams inside—and the browser or device that must decode them—are what determine compatibility and size.
Container and codec are different jobs
A container is the file structure that keeps video, audio, timing, and metadata together. A codec is the method used to compress and decode an individual stream. MP4 and WebM are containers. H.264, VP8, VP9, AV1, AAC, and Opus are codecs. Saying only 'MP4 video' is therefore incomplete: two MP4 files can contain different codecs and have very different playback support.
Common web combinations are H.264 video with AAC audio in MP4, and VP8 or VP9 video with Opus audio in WebM. Other combinations exist, so a player must understand both the container and every codec inside it.
When MP4 is the safer delivery choice
MP4 with H.264 and AAC is usually the conservative choice when a file must open in a broad range of phones, desktop players, editing applications, slide software, and messaging systems. That compatibility does not mean every browser can encode the combination through MediaRecorder, even when the same browser can play it.
A local browser tool therefore has to test encoding support at runtime. If H.264/AAC recording is unavailable, producing WebM bytes and naming them .mp4 would create a misleading file that strict applications reject. A disabled MP4 option is more useful than a fake successful download.
When WebM makes sense
WebM was designed for web media and commonly carries VP8 or VP9 video with Opus audio. It is an open container and works well in current browsers. It is a practical fallback for browser-native recording and conversion because WebM encoders are widely exposed through MediaRecorder.
The tradeoff appears outside the browser: an older editor, presentation application, television, or social workflow may expect MP4. Choose WebM when the destination accepts it or when a browser cannot produce genuine MP4 locally; choose a supported MP4 path when interoperability matters more.
What conversion must—and must not—do
Real conversion decodes the input streams and writes newly encoded streams into the requested container. It may change quality, bitrate, resolution, and audio characteristics. Renaming an extension changes none of those things. Remuxing changes only the container and works only when the destination container permits the existing codecs.
HateItAll uses runtime capability checks, writes the selected supported format, verifies its binary container signature, and reopens the result for playback. If the browser cannot make the requested combination, the interface says so rather than relabelling incompatible data.
Sources and standards
We used the following format and browser documentation when reviewing this guide: