Sample MKV Generator
Generate a genuine Matroska video file in seconds — seven video content types, real VP9/Opus encoding, a real embedded subtitle track, real Tags metadata, and an exact target file size. Runs entirely in your browser.
Quick Tips for the Right Test Container
Features
One Real File, Two Valid Profiles
WebM isn't a different technology from Matroska — it's Matroska, deliberately restricted. The spec defines WebM as a strict subset: a small, fixed list of allowed codecs (VP8, VP9, Opus, Vorbis) inside the exact same EBML container Matroska itself uses. That relationship is what makes this generator possible without reinventing anything Sample WebM already got right — the same real VP9/Opus stream your browser produces is, byte for byte, already valid Matroska before this generator touches it at all.
What this generator actually changes is the file's own declaration of itself — the EBML header's DocType field, patched from "webm" to "matroska" — plus real structure the WebM profile doesn't allow: a second track type and a metadata system neither of which exist in the file until this generator adds them for real.
A Second Track That Was Never Recorded
MediaRecorder only ever captures what you hand it — a canvas, a microphone, a tone — and there's no way to hand it subtitle text, since subtitles aren't a media stream at all. So the subtitle track here doesn't come from the recorder; it's built and inserted afterward, directly into the file's own structure. A real track entry gets added to the track list, assigned a track number one higher than anything the browser's muxer already used, with Matroska's own S_TEXT/UTF8 codec identifying it as plain UTF-8 subtitle text rather than compressed video or audio.
The actual cue text lives in its own small Cluster, appended after the recorded video — Matroska never requires every track's data to share one Cluster, so a self-contained block carrying just the subtitle cues, each with its own real BlockDuration timing field declaring exactly how long it should stay on screen, is entirely valid structure on its own.
Tags, Not Just a Rename
Title, Artist and Description here don't live in a comment or a filename — they're written as real Matroska Tag elements, TagName paired with TagString, the format's own native metadata mechanism. It's a genuinely different structure from Sample MP3's frame-based ID3v2 tags or Sample OGG's Vorbis-comment key-value pairs, even though all three exist to answer the same basic question a media file asks about itself.
It's also genuinely new ground for this generator's own WebM sibling specifically — Sample WebM's restricted profile carries no title or artist metadata at all, so this is the first tool in the video half of this library where that information lives inside the file itself rather than only in the download's filename.
Why Matroska Chose to Be Extensible in the First Place
Matroska's original design goal was an open container that could hold effectively anything a media file might need — multiple audio tracks in different languages, several subtitle tracks, chapter markers, attachments, rich native metadata — without needing a new container format invented every time a new use case showed up. That's a genuinely different philosophy from a format like WebM, which exists specifically to be narrow and predictable for browser playback, or a purpose-built format like WAV, which was never designed to carry a subtitle track at all.
This generator only demonstrates a small slice of that real extensibility — one subtitle track, one set of Tags — but the mechanism is the same one a production Matroska file with a dozen tracks relies on: track entries are independently numbered and typed, so a file can keep growing new capability without ever breaking a player that only understands the tracks it already recognizes.
Who Actually Needs a Real Test MKV
Developers building or testing a video player's subtitle handling need a file with a genuinely separate, independently timed text track, since a player that renders baked-in captions correctly can still fail to detect or sync a real subtitle track. Media library and transcoding tools that specifically branch on container profile — treating Matroska differently from WebM even when the underlying codecs match — get more honest test coverage from a file that's actually declared as Matroska than from a WebM file quietly renamed.
Subtitle-authoring and captioning tool vendors also benefit from a genuinely minimal but real multi-track file to develop against, since a synthetic file this small still forces correct handling of independent track numbering and timing rather than special-casing a single, already-familiar sample.
QA teams validating multi-track playback end-to-end benefit from a file that genuinely exercises more than one track type at once, the same way testing several Sample GIF content types on purpose reveals bugs one convenient file never would.
Where a Relabeled Container Still Has Limits
This generator produces exactly one video codec — VP9 — since codec choice was already the point of Sample WebM, and duplicating that selector here would add complexity without adding anything genuinely Matroska-specific. It also can't add codecs a browser genuinely can't encode, like H.264 inside an MKV wrapper or DTS audio, since this library never fakes an encoding step it can't actually perform. Resolution stops at 1080p for the same reason it does throughout this library's video tools: sustained real-time software encoding in a browser tab is heavier work than a single rendered frame.
The subtitle track itself is deliberately simple, too — two short, generated cues describing the content type and confirming the track is real, not a full imported SRT or VTT file with arbitrary cue counts and styling. That's an honest scope choice rather than a technical ceiling: proving a genuinely separate, correctly timed track exists doesn't require dozens of cues, just enough to demonstrate the mechanism actually works and give a real player something genuine to render and time correctly.