Convert WebM to MKV
Move a WebM into an MKV container without re-encoding anything. These two are closer than any other pair on this site: WebM is Matroska with a restricted set of codecs, so this is less a conversion than removing a restriction. The streams are copied across untouched and it finishes in seconds.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your WEBM file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- Streams copied, not re-encoded — identical quality
- WebM is a subset of Matroska, so nothing has to change
- Media servers and desktop players handle MKV better
- No watermark and no sign-up
How to use WebM to MKV
- 1
Add the WebM
Drop the file in or choose it from your computer, up to 50 MB, no account needed.
- 2
Convert
The streams are copied into an MKV with `-c copy`. Nothing is decoded and nothing is encoded.
- 3
Use it
The MKV plays in VLC, MPV and every media server, and will take tracks WebM would have refused.
The closest pair on this site
Most format conversions move between designs that solve the same problem differently. This one moves between a format and a deliberately restricted version of itself.
WebM was published by Google in 2010 as a subset of Matroska. Same underlying structure, same container design, with the codec list narrowed to VP8, VP9 and AV1 for video and Vorbis and Opus for audio — everything royalty-free, so that browsers could implement it without patent licensing. That restriction is the whole point of WebM's existence.
An MKV has no such list. It will hold all of those and everything else besides.
How it works
The streams are copied into an MKV container with -c copy. No frame is decoded
and no encoder runs, so the conversion is bounded by reading and writing the file
rather than by its length. The video stream's checksum is identical before and
after.
What the restriction was costing you
WebM's specification does not provide for subtitle tracks, and browsers expect captions to arrive separately as a WebVTT file referenced from the page. That is a good arrangement on a web page and no help at all in a media library, where the subtitle needs to travel inside the file.
The same applies to additional audio: a second language, a commentary track, an isolated microphone. And to chapter markers.
Remuxing to MKV makes all of that possible without touching a frame of video, which matters because adding subtitles to a file by re-encoding it costs quality for no reason.
Where WebM should stay WebM
Anywhere a browser is going to play it. Browsers implement WebM deliberately and do not accept MKV, even when the file holds exactly the same streams — the container declaration is what they check.
So if the file is for a web page, this conversion makes it worse and gains nothing. It is for the other direction: a download that is going into a library, a player, or an editing step that wants Matroska.
What a media server actually does with each
Worth knowing before you decide, because browser support and media-server support point in opposite directions here.
Plex, Jellyfin and Kodi are built around Matroska. They read its track structure natively, expose subtitles and alternative audio as things a viewer can switch between, and index chapters. Handed a WebM they generally cope, less consistently, and frequently re-encode it on the way to a client — which costs CPU and quality for a file that needed neither.
Remuxing first means the server gets what it expects, at no cost, and the video reaches the client untouched.
Examples
A browser download going into a media library
Plex, Jellyfin and Kodi are built around MKV and index it properly. WebM support in media servers is patchier than its browser support suggests.
A file that needs another audio track
WebM restricts what it will carry; MKV does not. Remuxing first means a second language or a commentary can be added without touching the video.
Frequently asked questions
Is WebM really the same thing as MKV?
Structurally, nearly. WebM was defined as a subset of Matroska with a restricted codec list — VP8, VP9 and AV1 for video, Vorbis and Opus for audio — so that browsers could implement it without patent exposure. An MKV can hold all of those and a great deal more. Going from WebM to MKV therefore removes a restriction rather than changing a format.
So does anything actually change?
The container declaration and what the file is now permitted to hold. The video and audio are identical, which was verified by comparing the stream checksums. What you gain is the ability to add subtitle tracks, extra audio tracks and chapters, none of which WebM's specification allows.
Will it play in a browser afterwards?
No, and that is the trade. Browsers implement WebM specifically and do not accept MKV, even holding exactly the same streams. If the file is going onto a web page, leave it as WebM. Convert when it is going into a media server, a desktop player, or an editing step that wants Matroska.
Should I convert to MP4 instead?
If the destination is a phone, a browser or a smart TV, yes — those want H.264, which means a real re-encode with a real cost. This conversion is the opposite: free, instant, and useful only where MKV is what is wanted.