Convert WebM to MKV — Free Online Tool
Convert WebM files to MKV by re-encoding the VP9 video stream to H.264 (libx264) and transcoding Opus audio to AAC — producing a widely compatible Matroska file that plays on virtually every media player and device. Ideal when you need to move WebM content out of browser-only environments without sacrificing the flexible multi-track, subtitle, and chapter support that MKV offers.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your WebM file here
or click to browse
Free — no uploads, no signups. Your files never leave your browser.
Settings
Note: Browser-based encoding uses approximate quality targets. For precise CRF compression, copy the FFmpeg command above and run it on your desktop.
Estimated output:
Conversion Complete!
DownloadHow It Works
WebM is essentially a restricted subset of Matroska, so the container switch is structurally simple — but the codecs inside require full re-encoding. The VP9 video stream is decoded and re-encoded to H.264 using libx264 at CRF 23, which is a widely accepted balance of quality and file size for H.264. The Opus audio track is decoded and re-encoded to AAC at 128 kbps, since AAC is far more universally supported than Opus in standalone media players and hardware decoders. Any subtitles and chapter metadata present in the source WebM will be carried over into the MKV container, which natively supports both.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg program, which is the underlying engine powering this browser-based conversion via its WebAssembly (FFmpeg.wasm) port. The same binary and command run identically on a desktop installation of FFmpeg for files over 1GB. |
-i input.webm
|
Specifies the input file — a WebM container, which holds a VP9 video stream and typically an Opus audio stream. FFmpeg reads and demuxes this file to extract the individual streams for re-encoding. |
-c:v libx264
|
Tells FFmpeg to re-encode the video stream using the libx264 encoder, converting it from VP9 to H.264. H.264 is chosen here for maximum hardware and software playback compatibility in the MKV output, unlike VP9 which is optimized for browser delivery. |
-c:a aac
|
Re-encodes the audio stream from Opus (the WebM default) to AAC using FFmpeg's built-in AAC encoder. AAC is the standard for broad compatibility with media players, hardware devices, and operating systems that may not support Opus decoding natively. |
-crf 23
|
Sets the Constant Rate Factor for the libx264 video encoder to 23, which is the widely recommended default for H.264. This controls quality versus file size: at CRF 23, the encoder targets visually transparent quality for most WebM source content without producing unnecessarily large output files. |
-b:a 128k
|
Sets the AAC audio bitrate to 128 kilobits per second, which is generally considered the minimum for transparent-quality stereo audio in AAC. This replaces the Opus stream, which is highly efficient at this bitrate, so increasing to 192k is recommended for music-heavy WebM sources. |
output.mkv
|
Defines the output file as a Matroska (.mkv) container. FFmpeg infers from the .mkv extension that it should mux the re-encoded H.264 video and AAC audio — along with any subtitles or chapters from the source WebM — into the Matroska format. |
Common Use Cases
- Making a WebM screen recording or gameplay capture playable in desktop media players like VLC, PotPlayer, or Kodi that have limited or no VP9/Opus hardware decoding support
- Preparing WebM video downloaded from a web source for import into video editors such as DaVinci Resolve or Premiere Pro, which handle H.264-in-MKV more reliably than VP9-in-WebM
- Archiving browser-based video content (e.g., WebM exports from online editors) in MKV with H.264, ensuring long-term playback compatibility across operating systems
- Converting a WebM lecture or webinar recording to MKV so it can be embedded or distributed via platforms and LMS systems that accept H.264 video but reject VP9
- Preserving multi-audio-track or subtitled WebM content in MKV format where downstream tools or team members need H.264/AAC without losing subtitle or chapter data
- Transcoding WebM animation or screen-captured tutorial files to H.264/MKV for upload to internal company video portals with strict codec requirements
Frequently Asked Questions
Yes, some quality loss is unavoidable because both the video and audio streams must be fully re-encoded rather than copied. VP9 is generally more efficient than H.264 at the same bitrate, meaning the H.264 output at CRF 23 may be slightly larger or marginally lower in quality than the original VP9 at an equivalent CRF. For most practical content — screen recordings, web video, lectures — the difference at CRF 23 is imperceptible. If you want higher fidelity, lower the CRF value (e.g., to 18) in the FFmpeg command.
MKV technically supports Opus audio, but the conversion targets maximum compatibility — AAC is natively decoded by nearly every hardware media player, smart TV, and non-browser software, whereas Opus support is inconsistent outside of browser and open-source player ecosystems. Re-encoding Opus to AAC at 128 kbps introduces minimal perceptible quality loss for speech, music, or general content, while dramatically broadening where the output file can be played without installing additional codecs.
Yes. Both WebM and MKV are based on the Matroska specification, so subtitle tracks and chapter markers present in the source WebM are structurally compatible with MKV and will be carried over during the conversion. The FFmpeg command does not explicitly strip subtitle or chapter streams, so they are included in the output by default. You can verify this after conversion by opening the MKV in a player like VLC and checking the subtitle and chapter menus.
No. WebM with VP9 supports an alpha channel for video transparency, but H.264 (libx264) does not support alpha channels. The transparency information will be lost during re-encoding, and the output MKV will have a solid background — typically black — where transparent regions existed. If you need to preserve transparency, you would need to use a different video codec in the MKV, such as PNG or VP9, which this default command does not do.
To adjust video quality, change the CRF value in the command: lower numbers (e.g., -crf 18) mean higher quality and larger file size, while higher numbers (e.g., -crf 28) reduce quality and file size. The H.264 CRF scale runs from 0 (lossless) to 51 (worst). To change audio bitrate, modify the -b:a value — for example, replace 128k with 192k for higher-quality audio or 96k to reduce file size. A full adjusted example: ffmpeg -i input.webm -c:v libx264 -c:a aac -crf 18 -b:a 192k output.mkv
Yes. On Linux or macOS, you can batch process all WebM files in a directory with a shell loop: for f in *.webm; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "${f%.webm}.mkv"; done. On Windows Command Prompt, use: for %f in (*.webm) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "%~nf.mkv". This is especially useful for files over 1GB that exceed the browser tool's limit.
Technical Notes
This conversion involves a generation loss at both the video and audio layers. The source VP9 codec in WebM is a highly efficient modern codec, and H.264 requires somewhat higher bitrates to achieve equivalent visual quality — this means the MKV output may be modestly larger than the source WebM for the same perceived quality, or slightly softer at the same file size. The libx264 encoder with CRF 23 is a widely used default that produces visually transparent results for most content types; for high-motion or high-detail video (e.g., gaming footage), consider CRF 18–20. On the audio side, Opus at 128 kbps typically outperforms AAC at the same bitrate in perceptual quality, so some very subtle audio degradation is possible, particularly on music-heavy content — using -b:a 192k or higher mitigates this. Notably, WebM's support for HDR metadata (via VP9 Profile 2) may not be fully preserved in the H.264 output, since HDR in H.264-in-MKV requires specific signaling that this default command does not explicitly configure. If HDR preservation is critical, consider encoding to H.265 (libx265) instead of H.264. Multiple audio tracks from the source WebM should pass through correctly, as MKV fully supports them. The -b:v 0 flag is not included in this command because it is specifically a VP9 encoder flag for enabling pure CRF mode and is not applicable to libx264.