MP4 or WebM: which should you export?
A site wants MP4 and my file is WebM. Is that a conversion, or just a rename?
The question is really two questions
MP4 and WebM are containers. A container is a filing system: it holds one or more tracks, records their timing, stores the index that lets a player seek, and carries metadata. It does not compress anything. The compression is done by a codec, and the coded bitstream is what the container is carrying.
So "MP4 or WebM" is a packaging question, and "H.264, VP9 or AV1" is the compression question. Confusing them is why people re-encode files that only needed re-packaging, and lose a generation of quality for nothing.
What normally goes inside each
| Property | MP4 | WebM |
|---|---|---|
| Base format | ISO base media file format (ISO/IEC 14496-12) | A profile of Matroska |
| Usual video codecs | H.264, HEVC, AV1 | VP8, VP9, AV1 |
| Usual audio codecs | AAC, sometimes AC-3 or FLAC | Opus, Vorbis |
| Licensing character | Patented codecs are common | Designed around royalty-free codecs |
| Where it is the safe default | Phones, desktop players, editing software, social platforms | The web, especially with VP9 or AV1 |
Neither list is a rule. A container is largely codec-agnostic, and both can carry AV1. What varies is what the software on the other end is prepared to accept.
Where each one actually plays
MP4 carrying H.264 and AAC is the closest thing to a universal video file. It plays on phones, on televisions, in editing software, in messaging apps, and it is what upload forms usually mean when they say "video". Its dominance is why hardware decoders for H.264 are in essentially every device shipped for the last fifteen years, which matters for battery life as much as for compatibility.
WebM was built for the web, with codecs that carry no royalty obligation for streaming. Browsers handle it well. Non-browser software is less reliable: some editing tools, some televisions and some phone galleries will not open it, and a colleague who double-clicks it may see nothing at all.
Remuxing versus re-encoding
If the codec inside your file is already acceptable to the destination, changing containers is a remux: the coded frames are copied across unchanged and only the packaging is rewritten. It is fast, it is lossless, and the picture is bit-identical. If the codec is not acceptable — VP9 into an MP4 for a player that only reads H.264 — then the frames must be decoded and encoded again, which takes real time and costs a generation of quality.
That is why the useful first question is "what codec is in there", not "what extension does it have". FileSlimmer's video tools inspect the tracks first and remux instead of re-encoding whenever the destination allows it.
Do not forget the audio track
A container swap that ignores audio produces a silent file on the wrong player. MP4 conventionally carries AAC; WebM conventionally carries Opus or Vorbis. Putting Opus into an MP4 is legal in the specification and unsupported by a great deal of software in the wild, so an honest conversion to MP4 usually means encoding the audio to AAC as well.
If a clip has no audio at all, say so explicitly in whatever you export. Some players stall when they expect a track that is not there.
A short decision list
- Sending the file to a person, a platform or an upload form: MP4 with H.264 and AAC.
- Serving the file yourself, from your own pages, to browsers: WebM with VP9, or AV1 in either container, with an MP4 fallback if your audience is broad.
- Editing later: keep the highest-quality original you have, in whatever container it came in.
- Only the container is wrong and the codecs are already right: remux, do not re-encode.
- You are unsure what is inside: check the codecs before choosing, because the answer decides whether this costs you seconds or an hour.
Limits worth knowing
Browser video encoding depends on what the device exposes. Hardware encoders are format-specific: a machine may encode H.264 quickly and VP9 slowly, or refuse a codec entirely. Support also differs between browsers on the same machine, and between a browser and the same browser on a phone. A conversion that runs in seconds on a laptop can take much longer on a phone that is also managing its own temperature.
Container choice cannot rescue a file that is large because of its content. A long clip, at a high resolution, with a lot of motion, is large in any container. Resolution, bitrate and duration decide that, and no repackaging changes them.
Tools for this
Sources
- ISO/IEC 14496-12 — ISO base media file format
- The WebM Project — container guidelines
- ITU-T H.264 — Advanced Video Coding
- MDN — Media container formats and codec support