Convert MKV to WebM

This is the relationship worth understanding before converting anything. WebM is not a separate design; it is Matroska with the permitted contents cut down to a handful of codecs — VP8, VP9 and AV1 for video, Opus and Vorbis for audio. A WebM file is a legal Matroska file, and the parser reading it is the same parser.

The restriction is the entire value. A browser handed an arbitrary MKV cannot know whether it contains HEVC, DTS, TrueHD or something from 2004, so it declines the whole class rather than failing halfway through playback. A browser handed a WebM knows in advance that it is one of five things it can decode. Converting is therefore less about changing the file than about making a promise the browser is willing to accept.

Video sites serve their best streams as VP9 or AV1 with Opus audio, and none of those belong in an MP4 that anything will play. So a download tool that merges the separate video and audio streams has to put them somewhere permissive, and Matroska is the container that accepts every combination without argument. That is why the file on your disk is an MKV even though nothing about it is a film.

The consequence is unusual for this bundle: the codecs you want in the WebM are, more often than not, already sitting inside the MKV. That makes the conversion cheap in one sense and worth thinking about in another, because it is exactly the case where a copy would have been possible and this tool does not do one.

It would be reasonable to assume that a VP9 track going into a WebM is copied across untouched. It is not. Every frame is decoded back to pixels and compressed again, and a second pass through a lossy codec always loses a little more of what the first pass approximated. On a screen recording or a talking head this is genuinely hard to see; on grain, water or fast panning it is visible if you compare.

It is worth being blunt about the alternative, because for this particular file it is a good one. If MediaInfo says your MKV already holds VP9 and Opus, ffmpeg with a stream copy, or MKVToolNix, will produce the WebM in seconds with nothing lost at all. Use this page when the source is something else, when the file needs resizing anyway, or when installing a desktop tool is not worth it for one clip.

The output holds VP9 video and Opus audio, every time. An AV1 source is converted down rather than kept, which is a small loss of efficiency in exchange for a wider set of machines that can decode it. `vp09.00.31.08` is the string the browser is asked about before the conversion starts; it describes a 1280×720 probe, not the file you get, because the level digits are derived from the frame size — 40 for 1080p, 50 for 4K.

Current Chrome, Edge, Firefox and Safari all play that combination. Older Safari on older macOS is the exception that keeps MP4 in the picture, which is why a production `<video>` element normally lists both sources and lets the browser choose the first one it understands. Serving only WebM is a decision about which visitors you are willing to lose.

WebM inherits Matroska’s room for multiple audio tracks, and every one the browser can decode is carried into the output in the order it was found. In practice a downloaded clip has one, so this matters less here than it does on the MP4 and MOV pages — but nothing is thrown away to make the file smaller.

Subtitle tracks are a different story and the story is short: this converter reads video and audio tracks only, so a soft-subbed MKV is invisible to it in that respect. For a page you control, that is not much of a loss. A WebVTT file referenced from a `<track>` element inside your `<video>` gives you captions the browser can style, a search engine can read and a visitor can copy, which an embedded track never does.

The browser is asked whether it can decode each soundtrack before anything is converted. If it cannot, the track is dropped and the picture carries on, so the conversion succeeds and the WebM has no sound. Nothing warns you while it is happening.

A downloaded MKV carries Opus or AAC and is never affected. An MKV taken off a DVD or a Blu-ray carries AC-3, E-AC-3, DTS or Dolby TrueHD, and those are the codecs no browser ships a decoder for. If you are converting disc material for a page, play the WebM before you publish it — a silent hero video is the sort of thing nobody notices until a visitor mentions it.

For anything embedded on a page, the resolution control matters more than the quality band. A 4K source dropped to 1080p removes three quarters of the pixels and takes most of the bytes with it, and for a clip that will be displayed in a 700-pixel-wide column, every pixel above that is downloaded and thrown away by the browser on arrival.

The control only ever reduces. Asking for more than the source has is ignored deliberately, because upscaling invents no detail and produces a larger file for nothing. If the clip is decorative — a background loop, an autoplaying demo — 720p at the small quality band is usually indistinguishable in place and a fraction of the transfer.

The decoding and the VP9 encoding both happen inside the browser tab. Nothing carrying the video is sent anywhere, which you can confirm by opening the network tab and converting something. There is no account and no queue behind anyone else’s upload.

VP9 asks more of the processor than H.264 does, and hardware VP9 encoders are less commonly fitted, so the browser sometimes falls back to software and the wait is longer than you would expect for the file size. That cost is bought back on every page load afterwards: for the same visible quality VP9 typically needs meaningfully fewer bytes than H.264, and a video is usually served far more often than it is encoded.