Convert MKV to WebM
Re-encode an MKV as a WebM that a browser will play. No browser plays MKV — it is a desktop and media-server format — so anything destined for a web page has to change container and usually codec too. This is a full re-encode to VP9 and Opus, which takes real time, and the MKV is very likely too long to upload without trimming first.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your MKV file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- VP9 video and Opus audio
- Playable in every modern browser
- Royalty-free, with no patent licensing
- No watermark and no sign-up
How to use MKV to WebM
- 1
Trim the MKV first
These files are usually long. Cut the section you need with VLC or MKVToolNix, which can split without re-encoding.
- 2
Add the clip
Drop the trimmed file in or choose it from your computer, up to 50 MB.
- 3
Serve it with a fallback
Put the WebM first in your video element and an MP4 second, so every browser gets something it can play.
A desktop format meeting the web
MKV is excellent at what it was built for: holding anything, cleanly, for as long as you like. Several video tracks, a dozen audio tracks, subtitles as real text, chapters, attachments. Desktop players and media servers read it natively.
Browsers do not, and never have. The web settled on two containers — MP4 and WebM — and MKV is neither. So a recording that plays perfectly in VLC and on a Plex server cannot be embedded in a page at all without conversion.
Trim before you upload
This matters more here than for most pairs. MKV is the format people use for long recordings, so the file is frequently gigabytes while the upload limit is fifty megabytes.
Cutting first is quick and, done properly, free. MKVToolNix splits by timecode without re-encoding anything, and VLC can record a section during playback. Cut the piece you actually intend to publish, then convert that.
How it works
The video is re-encoded to VP9 and the audio to Opus inside a WebM container. Both are full re-encodes — nothing is copied — so this takes real time and costs the small amount of quality any re-encode costs.
VP9 is considerably more expensive to encode than H.264, which is the trade for its efficiency. The settings used here favor finishing over squeezing out the last few percent of file size.
Screen recordings are the best case
If the MKV came from OBS or similar capture software, expect a large reduction and do not assume something went wrong.
VP9 stores what changed between frames rather than each frame whole, and a screen recording changes very little — a still window, a flat background, a cursor moving across a few hundred pixels. The encoder spends almost nothing on the rest, and the WebM can be a small fraction of the source with no visible difference.
What does not come across
Subtitles are the significant loss. MKV holds them as text tracks a viewer can switch on; WebM has no equivalent that browsers act on.
The web's answer is better than the one you are losing: a separate WebVTT file referenced from the video element. Browsers render it as real captions, it can be translated, and search engines can read it — none of which is true of subtitles burned into a picture.
Examples
A screen capture for a documentation page
OBS records MKV by default. Screen content compresses extremely well with VP9, so the WebM is often a fraction of the source.
A trimmed clip for a web article
Cut the section you want first — the whole MKV will not fit under the upload limit and a web page does not want a full recording anyway.
Frequently asked questions
Why will a browser not play MKV?
Because no browser vendor ever implemented it. MKV is a desktop and media-server format — VLC, MPV, Plex and Kodi all read it — and the web settled on MP4 and WebM instead. It is not a limitation of the file; the browser simply has no code for that container, whatever is inside it.
Why is this slower than converting to MP4?
Because VP9 encoding is far more computationally expensive than H.264. That expense is what buys the efficiency — VP9 spends more effort deciding how to represent each frame and produces a smaller file. The settings here are chosen so a conversion completes in reasonable time rather than reaching the smallest possible output.
Should I convert to WebM or MP4 for the web?
Serve both. An HTML video element takes several sources and the browser plays the first it supports, so WebM first and MP4 second gives modern browsers the smaller file and everything else a working one. Converting to only one means either larger downloads for everybody or nothing at all for some visitors.
Do subtitles come across?
No. MKV stores subtitles as selectable text tracks, often several, and that is one of the main reasons people use it. WebM has no equivalent support that browsers act on. For a web page the answer is a separate WebVTT file referenced from the video element, which browsers do handle and which is also better for accessibility and search.