WebM file format
An open, royalty-free video container built on Matroska/EBML.
- MIME type
- video/webm
- Extensions
- .webm
- Category
- Video
Magic-number signature
| 0x00000000 | 1A45DFA3 | ·E·· | EBML header |
The EBML DocType string near the start reads 'webm' (vs 'matroska' for MKV).
About the WebM format
WebM is the royalty-free container Google defined for HTML5 video, pairing VP8, VP9 or AV1 pictures with Vorbis or Opus sound. It is not a new format so much as a deliberately narrowed one: WebM is Matroska with the codec list cut down to things that can be shipped without licensing, and the two share the same EBML encoding byte for byte. EBML is a binary cousin of XML — every element is a variable-length identifier, then a variable-length size, then either a value or more elements — which means a WebM file has no fixed layout past the first few bytes, and a parser has to walk it rather than index into it. The file opens with the EBML header, a small master element describing how the rest is encoded, and the DocType string inside it is the single field that separates WebM from plain Matroska.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 4 | EBML master element ID | 1A 45 DF A3. This is the whole magic number, shared identically with Matroska, and it is the only byte string in the file guaranteed to be at a fixed position. |
| 4 | 1 | EBML header size | A variable-length integer: the leading 1 bit marks it as one byte long and the remaining seven bits give the value. 9F is 31, the byte count of the header body that follows. Writers may pad this integer out to as many as eight bytes, so treat it as one to eight bytes rather than exactly one. |
| 5 | 4 | EBMLVersion element | 42 86 81 01 — a two-byte element ID, a one-byte size of 1, and the value 1. Every element in the EBML header has a default and may be left out entirely, which is why the offsets from here down are what a typical writer produces rather than what the specification pins. |
| 9 | 4 | EBMLReadVersion element | 42 F7 81 01. The minimum version a reader must implement to make sense of the file. It has stayed at 1 since the format was published. |
| 13 | 4 | EBMLMaxIDLength element | 42 F2 81 04. The longest element identifier that appears in this file, in bytes. Four is the universal value and a parser can size its buffers from it. |
| 17 | 4 | EBMLMaxSizeLength element | 42 F3 81 08. The longest size field in the file, in bytes. Eight is standard and is what makes the unknown-size encoding described below eight bytes wide. |
| 21 | 2 | DocType element ID | 42 82. The element that names which EBML-based format this actually is, and the reason a WebM file and an MKV file cannot be told apart by their first twenty bytes. |
| 23 | 1 | DocType length | 84 — a one-byte variable-length integer holding 4, the length of the string that follows. In a Matroska file this byte reads 88 instead, because 'matroska' is eight characters, and every offset after it shifts by four. |
| 24 | 4 | DocType value | 77 65 62 6D, the ASCII letters webm. This is the field that decides the format. Everything before it is identical in a Matroska file and everything after it is laid out the same way. |
| 28 | 4 | DocTypeVersion element | 42 87 81 02. Which revision of the WebM element set the writer used. A reader that supports a lower version is expected to skip elements it does not recognise rather than fail. |
| 32 | 4 | DocTypeReadVersion element | 42 85 81 02. The minimum revision a reader needs in order to parse the file at all, as opposed to merely understanding every element in it. |
| 36 | 4 | Segment element ID | 18 53 80 67, the container holding every track, cluster, cue and tag in the file — effectively all of it. Its size field follows immediately, and in a file being written live that size is the all-ones unknown form. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| Matroska | The two are the same encoding and differ only in the DocType string at offset 24: 'webm' against 'matroska'. There is a shortcut visible even earlier, at offset 4 — because the DocType is four characters longer in Matroska, the EBML header size byte reads A3 (35) there and 9F (31) in a WebM file. The practical difference is codecs: a Matroska file may hold H.264, HEVC, AC-3 or DTS, none of which belong in WebM, and a browser will refuse them even though the container parses. |
| MP4 | No structural relationship whatsoever. MP4 is a tree of boxes with big-endian 32-bit sizes and its magic at offset 4; WebM is EBML with variable-length everything and its magic at offset 0. The confusion is entirely at the extension level, because both carry AV1 and Opus and both play in every modern browser, so files get renamed between them and then refuse to open. |
| MKA | An .mka is a Matroska file with only audio tracks, and .mks one with only subtitles. Neither has any distinguishing header byte — the DocType still reads 'matroska' — so the only way to tell is to walk into the Tracks element and read each track's type. The same is true of an audio-only WebM, which is what a browser produces when it records from a microphone. |
| Ogg | The other royalty-free container of the era, and not related at byte level: an Ogg file begins with the ASCII capital-O page marker 4F 67 67 53 at offset 0. Ogg carries Vorbis, Opus and Theora in a page-and-granule structure designed for streaming, while WebM inherited Matroska's clusters and cues. |
How these files break
- A live recording with no duration. A browser recording through MediaRecorder cannot know how long the Segment will be, so it writes the unknown-size form — every value bit of the size integer set to one, 01 FF FF FF FF FF FF FF in the eight-byte encoding that EBML permits precisely for this case. The file is completely valid and completely unseekable: players show no duration and the scrub bar does nothing until the file is remuxed.
- Missing Cues. The seek index is an optional element that a streaming writer never gets to append, so a WebM captured from a live source plays from the start and cannot jump. Nothing is damaged; a remux that copies the streams and writes a Cues element fixes it without touching a single compressed frame.
- Truncation. Because every element declares its length, a reader walks happily to the last complete cluster and then finds a size promising bytes that are not there. Most players show what decoded and stop; some report the whole file as corrupt, which is why the same truncated file behaves differently in two tools.
- The wrong codec inside a right-looking container. A file whose DocType says webm but whose tracks hold H.264 is not a WebM file in any useful sense. It parses, a hex dump looks clean, and every browser refuses it — the mismatch is in the CodecID string inside the Tracks element, not anywhere in the header.
- Prepended junk. An HTML error page saved under a .webm name puts readable text where 1A 45 DF A3 should be. Unlike MP4 there are no absolute file offsets recorded inside a WebM to break, so once the leading bytes are deleted the file is generally intact.
Where the format stands today
WebM exists because H.264 came with licence fees, and it succeeded at the specific job of giving the open web a video format nobody had to pay for. Every browser plays it, and it is what a browser produces when a page records the screen, the camera or the microphone. Where it wins outright is VP9 and AV1 delivery on the open web, and audio with Opus, which beats AAC at low bitrates by enough to matter for voice. Where it loses is everything touching hardware and Apple: Safari's support arrived late and stayed partial, phones decode H.264 in silicon and VP9 sometimes, and no television, camera or editing suite treats WebM as a first-class format. In practice sites serve both — WebM to browsers that ask for it, MP4 to everything else — and MP4 remains what you keep if you can only keep one.
Open WebM files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with WebM — compare their leading bytes.