Convert MKV to MP4 — container swap, subtitles, and multi-audio reality

The short version

1. Drop the .mkv on the video converter, pick MP4 as the output.
2. If the MKV holds H.264 or HEVC video with AAC audio (most TV rips, most screen recordings, most YouTube-DL output), we remux — copy the bytes into an MP4 wrapper. Lossless, seconds even on a 10 GB file.
3. If the audio is FLAC, we transparently re-encode just the audio to AAC at 192 kbps. Video still stream-copies.
4. Subtitles come across as MP4 mov_text if they're SRT/ASS-compatible. PGS/VobSub image subtitles either get dropped or optionally burned into the video.
5. Download.

If that fits your situation, stop reading. The rest of this post is for multi-audio movies, subtitle-format mismatches, the remux- vs-re-encode speed math, and an honest compare against HandBrake, VLC, and CloudConvert.

Why MKV and MP4 are almost the same file

Both are containers. A container doesn't store video directly — it stores boxes that point to video streams, audio streams, subtitle streams, and metadata. The codec inside each stream (H.264, HEVC, AV1, AAC, MP3, Vorbis, FLAC, Opus, AC-3) is what actually determines compression and quality. The container just decides what players know how to open the file and which codec combinations are allowed.

MKV (Matroska) and MP4 overlap heavily on the codec side. Both natively carry:

• H.264 (AVC) — the 2026 compatibility baseline. Plays on literally every device made this century.
• H.265 (HEVC) — roughly half the file size of H.264 at matched quality. Plays on modern iPhones, modern Android, Apple TV, Chrome/Edge with system codec, not Firefox.
• AV1 — the newest, ~30% smaller than HEVC, slow to encode, fast to decode on 2023+ hardware. Both MP4 and MKV support it but fewer players do yet.
• AAC — the universal audio codec for MP4. Decodes everywhere.

MKV additionally carries some codecs MP4 can't:

• FLAC audio — lossless; common on anime rips, music videos. MP4 technically supports FLAC in the 2018 spec update, but playback support is spotty (Safari, some mobile players reject it). We re-encode FLAC → AAC 192 kbps by default for reliable playback.
• Vorbis / Opus audio — open-format audio. Opus gets into MP4 in some recent tools, Vorbis doesn't.
• PGS / VobSub image subtitles — the bitmap subtitle tracks on Blu-ray and DVD rips. MP4 can't carry these as tracks; your options are burn-them-into-the-video or drop them.
• ASS / SSA subtitles with full styling — advanced subtitle format with fonts, positioning, karaoke timing. MP4's mov_text strips styling down to plain SRT; we preserve line breaks and basic italics but lose custom fonts.

For 95% of "MKV I downloaded that won't play in [player]", the video inside is H.264 or HEVC and the audio is AAC or AC-3. Everything remuxes cleanly. The other 5% is where you actually need to think about what you're doing.

Why every other converter re-encodes

CloudConvert, Convertio, Zamzar, and most "online MKV to MP4" sites re-encode your MKV by default — even when a remux would have produced an identical, playable MP4 in a tenth the time. Three reasons:

• One server code path is simpler. Always re-encode means one FFmpeg command, not two. Engineering cost wins over your bandwidth.
• Predictable output. Re-encoding normalizes everything to H.264 / AAC so they never have to answer "why doesn't this play?" tickets.
• Server CPU monetization. Re-encoding is what "premium" plans sell against free-tier rate limits. A remux finishes too fast to gate behind a paywall.

The cost you pay: a 10-minute 1080p H.264 MKV takes 4 seconds to remux on a modern laptop. A re-encode of the same file takes 2–4 minutes and introduces a generation of compression loss. For a 2-hour movie, you're choosing between 30 seconds of disk I/O and 30+ minutes of CPU time. Our video converter picks remux whenever the input codecs allow it.

When you actually need to re-encode

1. The audio track is FLAC (or Vorbis, or Opus)

If your MKV has FLAC audio — common on anime fan-subs, concert rips, and some 4K Blu-ray rips — MP4 in theory supports FLAC (since 2018's spec update) but in practice Safari, iOS, and many smart-TV apps reject it. The robust fix is an AAC re-encode at 192 kbps for stereo or 384 kbps for 5.1. This is faster than video re-encoding (audio is tiny by comparison) and takes maybe 10% of the time a full re-encode would.

2. The video codec isn't MP4-legal

Rare today, but occasionally you'll get an MKV with VP9 or some legacy codec. VP9 stays in MKV and WebM; it doesn't go into MP4 cleanly. A full H.264 re-encode is the only path. If your target is web playback anyway, consider keeping VP9 and switching the container to WebM via our video converter — lighter workflow.

3. The subtitles must be visible on every device

MKV can carry SRT, ASS, PGS, and VobSub subtitle tracks. MP4 can carry SRT-equivalent mov_text. That leaves styled (ASS) and image (PGS, VobSub) subtitles stranded. If your target device can't load external subtitle files and can't readmov_text toggling, the only reliable fallback is to burn the subtitles into the video. That's a full video re-encode because the subtitle pixels are being drawn onto each frame. Slow, but it guarantees playback.

4. The playback target doesn't support HEVC

HEVC-in-MP4 is fine on modern iPhones, Apple TV, Windows (with the paid codec extension), and Chromium. Firefox still refuses HEVC. Some older TVs refuse it. If you need truly universal playback, re-encode to H.264. File will be 1.8–2.2× larger; quality drop is invisible on first generation.

Multi-audio-track movies: the honest handling

Many MKV rips of movies bundle 3–5 audio tracks (original English, dubbed French, dubbed Spanish, director commentary, descriptive audio). MP4 technically supports multiple audio tracks — the container format allows it — but real-world playback is inconsistent:

• VLC, MPV, Infuse, Plex — read all MP4 audio tracks, offer a switcher. Fine.
• Safari, iOS native video — read the first track only. Others are silently ignored.
• Chrome / Edge HTML5 video — one track. Additional audio streams are invisible to JavaScript APIs.
• Most Android default players — one track.

Our default: we keep all audio tracks in the output MP4, in the same order as the MKV. If your player only exposes track one, you can pick which MKV track becomes track one in our settings. For iPhone-bound files, we recommend explicitly selecting the language you want as the primary track.

Subtitle handling: what survives the conversion

Subtitles are where MKV → MP4 gets genuinely lossy even on a remux. MKV can hold four subtitle formats and MP4 can carry one. Here's what we do with each input:

If you need styled anime subs preserved perfectly, keep the MKV — none of the common MP4 players will render ASS anyway, so converting makes your experience worse, not better. Use VLC or Infuse, point it at the MKV, and skip this step.

Remux vs re-encode: the speed math

The chart above shows measured times on two test clips — a 5-minute 1080p H.264 MKV (340 MB) and a 120-minute 1080p H.264 MKV (8.2 GB). Remux is essentially a disk copy: time scales with file size, capped by your SSD's read speed (usually 500 MB/s–3 GB/s). Re-encode is CPU-bound, and time scales with clip duration × resolution × codec complexity.

On a 2023 laptop (M2 MacBook Pro, x264 medium preset):

• 5-min remux: ~3 seconds. Disk-bound.
• 5-min H.264 re-encode: ~90 seconds.
• 120-min remux: ~25 seconds. Still disk-bound (it's just a bigger file).
• 120-min H.264 re-encode: ~38 minutes. Linear scale.

The difference gets dramatic on 4K HEVC sources: a 2-hour 4K re-encode can take 4+ hours on the same laptop. A 2-hour 4K remux still finishes in under a minute. This is why remux-first matters and why "converter" sites that always re-encode are quietly wasting your day.

How our tool compares (honestly)

MKV → MP4 is a solved engineering problem — every serious video tool can do it. Here's what you're actually choosing between in 2026:

Honest summary: if you're processing hundreds of MKVs a week with consistent encode settings, HandBrake wins. If you already know ffmpeg -c copy, use it. For one-off or occasional "I downloaded this MKV and it won't play in [app]" traffic, our MKV-aware video converteris the shortest path.

Privacy: why in-browser matters for large video

MKV files are often large — 2 GB for a TV episode, 10+ GB for a movie, 30+ GB for a 4K remux. Every mainstream web converter uploads the full file to their server, processes it there, and serves the output back. For video, three things compound:

• Upload dominates. A 10 GB MKV on a typical home connection is 30–60 minutes of upload. The actual remux is seconds. Browser-side means you start from time zero and your upstream bandwidth stops mattering.
• Personal content stays local. Home videos, ripped discs from your own collection, screen recordings — none of it leaves your laptop. The ffmpeg.wasm binary in our tool is sandboxed in the browser tab.
• Retention promises are promises. "Files deleted after 2 hours" is true until the breach disclosure says otherwise. Not uploading at all is the stronger guarantee.

Common questions

Is MKV better than MP4?

For storage and flexibility: MKV holds more codec types, supports more subtitle formats, is better for a media-server library. For compatibility and web playback: MP4 wins cleanly — every device plays it, HTML5 video works, streaming works. Pick based on destination, not a universal "better."

Will I lose quality converting MKV to MP4?

If the conversion is a remux (container swap only) — no. Video and audio bytes are copied across unchanged, bit-for-bit identical. If it's a re-encode (because your audio was FLAC, your subtitles are bitmap, your playback target hates HEVC) — yes, some loss, but at sane defaults (AAC 192 kbps, x264 CRF 23) it's transparent on a first generation.

Why is my MKV bigger than the same movie as MP4?

It probably isn't — identical video and audio streams produce identical file sizes regardless of container. The MKV wrapper costs ~1% more overhead than MP4, not 10%. If your MKV is noticeably larger, it's because the MKV was encoded at a higher bitrate (common on "remux" rips vs BDRips), not because of the container.

Can I keep all audio tracks when converting?

Yes. Our tool keeps every audio track from the MKV by default, copied into the MP4 in order. Whether your player exposes track switching depends on the player — VLC, Plex, Infuse, MPV all show a track switcher; Safari and iOS native video only use track one. You can reorder tracks before conversion so the primary language is first.

What happens to my subtitles?

SRT text subtitles convert cleanly to MP4 mov_textand stay toggle-able. ASS/SSA styled subs either convert with styling stripped (fast) or burn into the video (slower, preserves look). PGS/VobSub image subtitles from Blu-rays must burn in or be dropped — MP4 can't carry them as tracks.

Can I convert MP4 back to MKV?

Yes. The reverse direction is also a remux (since every MP4-legal codec is MKV-legal). Use the same video converter and pick MKV as the output format.

Do my files get uploaded?

No. ffmpeg.wasm runs in your browser tab, sandboxed. Your MKV is read locally, remuxed (or re-encoded) in memory, and written back as a download. The file never leaves your machine. For the related MOV case, see our MOV to MP4 guide. For extracting just the audio, our extract audio from video guide covers the stream-copy path.

Related reading

• Convert MOV to MP4 — the sibling post, same remux-first logic for QuickTime files.
• Extract audio from video — when you only want the audio track, not the whole MP4.
• Compare vs CloudConvert — when server-side makes sense and when it doesn't.

Ready?

Video Converter →. Drop your MKV, pick MP4, we figure out whether to remux or re-encode. Free, in your browser, no sign-up. For a quick MOV job instead, grab MOV to MP4.