Author: Fei Y (Page 4 of 19)

Fei is a skilled software engineer. He previously worked at Google and now at a startup. His expertise includes web media processing, cloud architecture, complex algorithms, and AI training and deployment. Beyond work, Fei enjoys diving into new knowledge and is a big fan of strategy games.

MKV to MP4 conversion — RedPandaCompress blog cover

MKV to MP4: Convert Matroska Files Without Re-Encoding

September 6, 2026 / Fei Y / 0 Comments

You downloaded a movie, exported a recording from OBS, or pulled a video off a friend’s drive, and it arrived as an .mkv file. It plays perfectly in VLC and nowhere else — not in your phone’s gallery, not in Premiere, not when you drag it into a Slack message. The fix is to move that video into an MP4 container, and most of the time that takes about ten seconds because nothing inside the file actually needs to change.

This guide explains when converting MKV to MP4 is a lossless ten-second operation and when it genuinely re-encodes your video, how to do it in your browser without uploading anything, and what happens to the subtitle and audio tracks that MKV files love to carry.

Why MKV files won’t play where you need them

MKV (Matroska) is a container — a box that holds a video track, one or more audio tracks, subtitles, chapters and metadata. It is technically excellent: open, flexible, and able to store almost any codec. That flexibility is also why so little consumer software accepts it. Apple’s ecosystem never adopted it, so MKV won’t open in QuickTime, iOS Photos, iMovie or Final Cut. Windows added partial support years ago but many editors and upload forms still reject it. Android playback is inconsistent. Most messengers and web platforms — email, Slack, Discord, WhatsApp, LinkedIn, learning-management systems — either refuse MKV outright or fail silently.

MP4 is the opposite: a narrower container that nearly every device and platform on earth can play. Converting from MKV to MP4 is mostly about swapping the box, not rebuilding what is inside it.

Remux vs re-encode: the only distinction that matters

There are two completely different operations hiding behind the word “convert,” and knowing which one you are doing tells you how long it will take and whether quality changes at all.

	Remux (rewrap)	Re-encode (transcode)
What happens	Video and audio streams are copied bit-for-bit into an MP4 container	Every frame is decoded and compressed again from scratch
Quality	Identical to the source — zero loss	Some loss; depends on the target bitrate
Speed	Seconds, even for a multi-gigabyte file	Roughly real-time — a 40-minute video takes tens of minutes
When it applies	The MKV already contains H.264 video and AAC or MP3 audio	The MKV contains HEVC (H.265), VP9, AV1, MPEG-2 or another codec MP4 handles poorly

Most MKV files you meet in daily life — 1080p movie downloads, TV episodes, OBS and Streamlabs recordings set to their default encoder — already hold H.264 video. Those convert by remux: the tool reads the streams, writes them into an MP4 wrapper, fixes the timestamps, and you are done before the progress bar finishes drawing. Blu-ray rips and files marked “x265” or “HEVC” are the common exceptions that must be re-encoded, because MP4 cannot cleanly carry the audio formats those files use and playback support for HEVC-in-MP4 is patchy anyway.

How to convert MKV to MP4 in your browser

The RedPandaCompress MKV to MP4 converter runs FFmpeg compiled to WebAssembly directly in the page. Your file is opened by the browser tab, processed on your own machine, and never sent anywhere.

Open redpandacompress.com/mkv-to-mp4 in any modern browser.
Drag your .mkv file onto the page, or click to pick it. Files up to 8GB work on desktop, 2GB on a phone.
The tool probes the file and tells you whether it will rewrap losslessly or re-encode. Press Start.
If it is a remux, wait a few seconds. If it is a re-encode, it runs in parallel WebAssembly workers at roughly real-time speed — you can leave the tab open and come back.
Download the MP4. The original MKV on your drive is untouched.

Because there is no upload and no server queue, the only thing that determines speed is your own computer — not your connection, and not how many other people are using the site.

What happens to subtitles, extra audio and chapters

This is where MKV’s flexibility bites. A single MKV can hold five audio languages, three subtitle tracks and a chapter list. MP4 is far stricter, so a conversion has to make choices:

Audio: the first audio track is kept. AAC and MP3 are copied unchanged; other formats — PCM from a camera, Vorbis, Opus, or the DTS and Dolby TrueHD common in Blu-ray rips — are converted to AAC so the MP4 plays everywhere. Extra language tracks are not carried over.
Subtitles: embedded subtitle tracks (SRT, ASS, or the image-based PGS from discs) are not moved into the MP4. If you need burned-in or sidecar subtitles, keep the original MKV or a separate .srt.
Chapters: chapter markers are dropped.

Practical takeaway: before converting, make sure the audio language and track you actually want is the first one in the file. VLC and MKVToolNix can reorder tracks if it isn’t.

A worked example: a 4.2 GB movie file

Say you have a 1080p film as a 4.2GB MKV. You check the details in VLC (Tools → Codec Information) and see the video is H.264 and the audio is AAC. That is the happy path:

The converter rewraps it. Output: a 4.2GB MP4, pixel-for-pixel identical, produced in about 15 seconds.
It now plays on your iPhone, in Premiere, and uploads to any platform that took MP4 but choked on MKV.

Now say the same film is an “x265” release with DTS audio. The video must be decoded from HEVC and re-encoded to H.264, and the DTS track becomes AAC. On a modern laptop that is roughly a 25–40 minute job for a two-hour film, and the result will be close to the original visually but not bit-identical. If you have a choice at download time, grab the H.264 version — it converts in seconds and never loses a thing. If you only need MKV to MP4 and also want the file smaller, the main compressor lets you set a target size in the same in-browser workflow.

MKV to MP4 without uploading your files

MKV files are often large — full movies, hours of screen recording, camera archives. Most online converters ask you to upload that entire file to their servers, wait in a processing queue, and download it back. For a 4GB file on home internet that is a 20-minute upload before any work starts, and your video now sits on a third-party machine under whatever retention policy they run.

RedPandaCompress does the conversion in the browser tab itself. The file is read from your disk by local code, FFmpeg-in-WebAssembly does the remux or re-encode on your CPU, and the MP4 is written back to your Downloads folder. Nothing is transmitted — you can watch the network panel stay silent, or pull your Wi-Fi after the file is selected and the conversion still finishes. For anything you would not want to hand to a stranger, that is the difference that matters.

How it compares to typical online converters

	RedPandaCompress	Typical upload-based converter
Where it runs	Your browser, on your CPU	Their server
Free file-size cap	8GB desktop / 2GB mobile	Often 250MB–1GB before a paywall
Upload wait	None	Full file, before processing starts
Lossless remux for H.264 MKV	Yes, automatic	Sometimes; many always re-encode
File leaves your device	No	Yes
Watermark / signup	Neither	Common on free tiers

Frequently asked questions

Does converting MKV to MP4 reduce quality?

Not if the MKV already contains H.264 video — the streams are copied into the MP4 container untouched, so the result is identical to the source. Quality only changes when the video has to be re-encoded from HEVC, VP9 or another codec MP4 doesn’t support well.

Why is my converted MP4 the same size as the MKV?

Because a remux doesn’t recompress anything — it just changes the wrapper. If you want the file smaller you need to re-encode at a lower bitrate or set a target size, which is a compression job rather than a format conversion.

Can I keep the subtitles from my MKV?

Embedded subtitle tracks are not carried into the MP4. If you need them, extract the subtitle track to a separate .srt file first (VLC or MKVToolNix can do this), or keep the MKV for archival and use the MP4 only where you need compatibility.

Is there a file-size limit?

Up to 8GB per file on a desktop browser and 2GB on mobile, with no limit on how many files you convert and no signup. The cap comes from browser memory, not a pricing tier.

Does it work offline?

Once the page and its engine have loaded and you have selected your file, the conversion itself needs no connection — all the work happens locally. You can disconnect and the MP4 will still be produced.

Ready to convert? Open the MKV to MP4 converter and drop your file in — or head to RedPandaCompress if you also need to shrink it. Everything runs in your browser, and your video never leaves your device.

Fei Y

www.redpandacompress.com/blog

State of Everyday Video 2026 data report cover

The State of Everyday Video, 2026: What Tens of Thousands of Real Files Reveal

September 1, 2026 / Fei Y / 3 Comments

A data report from RedPanda Compress. All statistics are aggregates over tens of thousands of real-world video files analyzed in August 2026, with a September re-run added below — percent-only, no user-level data. Reuse welcome with attribution (see the end of the post).

September update: we re-ran everything — what moved, what didn’t

In September we re-ran every query on a fresh sample, with identical definitions so the two months compare like for like. The headline is how little changed: the shape of everyday video looks the same in two independent samples. The findings below still describe August; this section is the delta.

Metric	August	September
H.264 share of files	82.1%	80.5%
HEVC share of files	13.2%	14.8%
AV1 share of files	0.22%	0.26%
MPEG-4 Part 2 files per AV1 file	6.3	5.9
.mp4 files that aren’t H.264	14.8%	16.5%
Files longer than 1 hour	7.8%	7.3%
Desktop video that is portrait	23.2%	23.5%
Files under 2 Mbps (already compressed once)	24.9%	25.8%
Files above 20 Mbps	15.1%	14.8%
Compression jobs on ≤3G-class connections	9.8%	10.0%
Desktop files last touched by FFmpeg	41.7%	42.3%
Desktop files still carrying a camera fingerprint	11.8%	11.0%

What moved: HEVC keeps creeping up, and the “MP4 that isn’t H.264” is now one in six. H.264 lost 1.7 points and HEVC gained 1.6. The same shift shows up in desktop-only files (H.264 81.6% → 79.8%), so it isn’t just a change in the mix of devices. Inside .mp4 files, the non-H.264 share went from 14.8% to 16.5% (HEVC alone: 13.3%), so Finding 7’s “one in seven” is now closer to “one in six”. Across the September sample HEVC holds steady around 15% rather than climbing, so we read this as a drift toward a plateau, not a cliff. AV1 ticked up to 0.26% — still invisible, still outnumbered about six to one by the DivX-era codec.

What stayed put. Duration, orientation, bitrate, connection quality and FFmpeg’s share of the last-writer fingerprints all moved by roughly a point or less. Two independent samples landing on the same shape is the best evidence we have that these are properties of everyday video, not artifacts of one month’s traffic. The modal bitrate is still 5–10 Mbps (22.0%, was 23.2%), and about one file in four is still a re-compression of already-compressed video.

What faded: the sticker cluster. Square video is now 4.3% of desktop files (was 6.3%), and 44% of all square clips are below 360p (was 61%). The August “chat-sticker culture” cluster was real but not permanent — a reminder to read small, tight clusters in usage data as snapshots rather than trends.

Method notes for the update: orientation and resolution could not be determined for a larger share of desktop files in September (about 47%, up from about 38%), so every orientation figure remains known-only. Encoder-fingerprint rows use desktop files only, where the fingerprint could be read for about 98% of files in both months (the all-device August figure in Finding 6 was 41.0%). The mix of devices in our sample shifts from month to month, so where a comparison could be distorted by it we checked the desktop-only cut.

Methodology & privacy, up front

RedPanda Compress is a browser-based video compressor: files are processed entirely on the user’s device and never uploaded. The telemetry behind this report is deliberately coarse — pre-bucketed ranges (resolution class, duration range, bitrate range), codec names, and connection-quality classes. No filenames, no file contents, no metadata atoms (camera model, GPS), and no per-user profiles; the categories match our public privacy page.

Known biases: this is not a census of “all video” — it is a census of video people need to shrink, so heavy formats are overrepresented. Orientation and resolution could not be determined for roughly a third of files; those are excluded from the orientation and resolution figures. Connection classes come from the browser’s Network Information API, which estimates effective quality — “3G” means “performs like 3G,” not a cell contract. Encoder provenance was measured on a large subsample.

Finding 1 — H.264 is still 82% of everything. AV1 is statistically invisible.

Codec	Share of files
H.264/AVC	82.1%
HEVC/H.265	13.2%
MJPEG	1.6%
MPEG-4 Part 2 (the DivX/Xvid era)	1.4%
ProRes	0.23%
AV1	0.22%
VP9	0.18%
VP8	0.08%

Twenty-three years after standardization, H.264 remains the water everyone swims in. The striking pair: files encoded with ~2003-era MPEG-4 Part 2 still outnumber AV1 files six to one. AV1 has won the streaming-platform war — YouTube and Netflix serve it billions of times a day — but in the world of files people actually hold (camera output, exports, downloads, old archives) it has essentially no presence. Codec adoption in personal files is generational, not technological: files outlive the codecs that made them, and the encoder defaults of cameras and apps — not the preferences of standards bodies — decide what the world’s disks look like. The one codec visibly gaining is HEVC, and it is gaining the same way H.264 did: by being a phone camera default.

Finding 2 — “Video” no longer means “clip”

Duration	Share
< 15 s	11.8%
15–60 s	22.5%
1–5 min	30.1%
5–20 min	17.1%
20–60 min	10.5%
≥ 1 hour	7.8%

Nearly one file in five runs longer than 20 minutes, and roughly one in thirteen exceeds an hour — lectures, meetings, screen recordings, gameplay sessions. The mental model of compression as “shrink this phone clip” misses a fifth of the real workload: video is now also a document format, the recording of something that took an hour because the thing itself took an hour.

Finding 3 — Nearly a quarter of desktop video is vertical

Orientation of files processed on desktop computers (where orientation could be determined):

Orientation	Share of desktop files
Landscape	70.5%
Portrait	23.2%
Square	6.3%

Vertical video was born on phones, but it now flows routinely through desktop workflows — footage synced, transferred, or downloaded to a PC for editing and sharing. Desktop software that treats portrait video as an edge case is failing nearly a quarter of real files.

Inside the square segment hides this report’s favorite curiosity: 61% of all square videos are below 360p, and 71% run under 15 seconds — a distinct, many-user cluster consistent with animated chat-sticker and emote culture. Even a three-second looping sticker is worth compressing when a chat app enforces a size cap.

Finding 4 — The 5–10 Mbps world, and the quarter that’s already been compressed

Container bitrate (size × 8 ÷ duration) of source files:

Bitrate	Share
< 1 Mbps	10.7%
1–2 Mbps	14.2%
2–5 Mbps	16.1%
5–10 Mbps	23.2% (modal)
10–20 Mbps	20.4%
20–50 Mbps	9.3%
≥ 50 Mbps	5.8%

The modal file arrives at 5–10 Mbps — the default output of phone cameras and screen recorders. But the tails tell the story. One file in seven exceeds 20 Mbps — modern phones shooting high-bitrate 4K their owners immediately need to shrink. And a full quarter of files arrive below 2 Mbps: video that has already been compressed once, being compressed again to squeeze under some app’s attachment limit. Both tails are artifacts of the same mismatch — recording defaults and sharing limits are set by different companies, and users are stuck reconciling them.

Finding 5 — The users the cloud forgets

Roughly one compression job in ten starts on a connection the browser classifies as 3G-class or slower (per the Network Information API’s effective-quality estimate); on desktop alone the share is about one in twelve. The label surprises until you remember what the API measures: effective throughput, which sweeps congested Wi-Fi, VPNs, tethering, and ISP throttling into the same bucket as genuine 3G.

For this population, uploading a gigabyte of video to a cloud service is somewhere between painful and impossible. Client-side processing isn’t a privacy preference for them; it is the only version of the product that works at all.

Finding 6 — 41% of everyday video has been touched by FFmpeg

Video files carry faint fingerprints of the last software that wrote them. Classifying those fingerprints on a large subsample:

Last writer	Share
FFmpeg-family (Lavf muxer)	41.0%
Other/indeterminate tools	28.8%
Video editors	12.4%
Android phone cameras	7.7%
Unclassifiable	4.2%
Apple cameras	2.8%
Platform downloads (YouTube-style)	2.2%
Action cameras	1.0%

Two things stand out. First, FFmpeg — one open-source project — was the last tool to touch two files in five. It is the invisible plumbing inside converters, downloaders, editors, transcoding pipelines and apps that never mention it; no other single piece of software comes close.

Second, read the camera rows together: only about one file in nine still carries a camera’s own fingerprint. Everything else has already been through at least one piece of software — trimmed, converted, downloaded, re-muxed — before reaching us. The “original” straight-off-the-camera video is, by the time anyone needs to share it, a minority artifact.

Honest limits: the fingerprint only names the last writer, not the chain; “Lavf” is a giant catch-all for anything built on FFmpeg; and a missing fingerprint does not prove a file came straight from a camera.

Finding 7 — .mp4 is a monoculture, and one MP4 in seven is lying to you

By file extension, everyday video is astonishingly uniform: nine files in ten are named .mp4. MOV takes most of the rest (7%); MKV, AVI and WebM are all below 1% each. The container war is over.

But the label has quietly stopped meaning what people think it means:

What’s actually inside a `.mp4`	Share
H.264 (plays everywhere)	85.2%
HEVC	11.6%
MPEG-4 Part 2	1.3%
MJPEG	1.2%
AV1 + others	0.7%

14.8% of .mp4 files — one in seven — don’t contain H.264, and most of those carry HEVC, which still fails to play in many browsers and on many non-Apple devices. “It’s an MP4, it’ll play anywhere” was true for fifteen years; phone cameras defaulting to HEVC-in-mp4 have silently broken it. The extension names the box, not the contents — and the box is no longer a guarantee.

(A small aside for trivia lovers: 3% of files have no audio track at all — mostly screen recordings and camera timelapses.)

Summary for the impatient

H.264 is 82% of personal video; AV1 is 0.22% — still outnumbered 6:1 by DivX-era MPEG-4.
Nearly 1 in 5 files exceeds 20 minutes — compression is now a meetings-and-lectures workload.
23% of desktop video is vertical — and 61% of square video is sub-360p chat stickers.
The modal file is 5–10 Mbps, but a quarter of files are re-compressions of already-compressed video.
~10% of compression jobs start on ≤3G-class connections — the population client-side tools exist for.
FFmpeg was the last tool to touch 41% of files; only ~1 in 9 still carries a camera fingerprint.
90% of files are named .mp4 — but one MP4 in seven doesn’t contain H.264 and may not play everywhere.

Reuse this data

Data and charts may be reused with attribution and a link to redpandacompress.com. Questions about methodology: support@redpandacompress.com. All statistics are aggregates over coarse buckets; no user-level data exists to share. If you’re curious how a browser can analyze and compress video without uploading it, we’ve written up how the in-browser pipeline works and how to verify no upload happens.