Convert MKV to MP4

Pick a Matroska .mkv and get an .mp4 — a lossless container remux when possible, re-encode when needed. Runs in your browser, nothing is uploaded.

Try:
MP4 video

Convert MKV to MP4 in your browser

A Matroska .mkv and an .mp4 are both just containers — boxes that wrap already-compressed video and audio streams. When your MKV already holds the codecs MP4 uses (H.264 or HEVC video with AAC audio, which is what a huge share of MKV rips and recordings carry), converting it is just a remux: the video and audio packets are copied straight into an MP4 wrapper with no re-encoding. That's lossless, changes nothing about the picture or sound, and finishes in a fraction of a second.

Everything runs locally with ffmpeg compiled to WebAssembly — your file is never uploaded to a server, and the page keeps working offline once it has loaded.

Two modes

Both modes keep the video and audio and drop MKV-only extras — soft subtitles (SRT/ASS/PGS) and font attachments — that MP4 can't carry.

Worked example

Take a 6-second clip episode.mkv holding an H.264 video stream and an AAC audio stream. Leave the mode on Remux and drop the file in. Out comes episode.mp4 with the exact same H.264 and AAC streams — identical duration and dimensions, no visible change — ready to play on a phone, TV or anything that rejects .mkv.

If instead the MKV held VP9 video or FLAC audio, Remux would fail with a codec error; switch to Re-encode to H.264/AAC and it converts (re-encoding the picture to H.264 and the sound to AAC).

Limits

FAQ

Does converting MKV to MP4 lose quality?

In Remux mode, no — it's a lossless container change. The exact H.264/HEVC video and AAC audio streams are copied into the MP4 wrapper untouched, so the result is bit-for-bit the same media, just in a different box. Only Re-encode mode is lossy, because it genuinely re-compresses the picture and sound.

Why is the conversion so fast?

Because in the default Remux mode nothing is re-encoded. Re-encoding video is the expensive part; a remux only rewrites the container metadata and copies the already-compressed packets across with -c copy, so a short clip converts in well under a second.

My MKV won't remux — it errors. What now?

That means the MKV holds a codec MP4 can't carry — commonly VP8/VP9/AV1 video or FLAC/Vorbis/Opus audio. Switch the mode to Re-encode to H.264/AAC, which always produces a valid MP4. It's slower and lossy, so raise the quality slider if you want to preserve more detail.

What happens to subtitles and attachments in the MKV?

They're dropped. MKV can carry soft subtitles (SRT/ASS/PGS) and font attachments, but MP4 can't legally hold most of them — leaving them in makes an otherwise-convertible file error out. This tool keeps the video and every audio track and discards those MKV-only extras. If you need burned-in subtitles, use the video-caption-burner tool first.

What does the quality slider do, and when does it matter?

It only applies in Re-encode mode, where 1–100 maps onto a practical slice of ffmpeg's libx264 CRF scale (higher = better quality and a larger file): 100 is visually lossless (CRF 18), the default 75 is roughly CRF 24, and 1 is small and low quality (CRF 40). In Remux mode it's ignored entirely, because a stream-copy never re-encodes.

Is my video uploaded anywhere?

No. The conversion runs entirely in your browser using ffmpeg compiled to WebAssembly — the file never leaves your device, and the page works offline once it has loaded.

Developer & Automation Access

Run it from the terminal

Same engine as this page, headless — via the gizza CLI:

gizza tool mkv-to-mp4 'url=https://example.com/input' 'mode=copy' 'quality=75'

New to the CLI? Get gizza →

Open it by URL

Pre-fill and auto-run this tool with query parameters — the names match the API/CLI:

https://gizza.ai/tools/mkv-to-mp4/?url=https://example.com/input&mode=copy&quality=75

Machine-readable descriptor: tool.json — title + parameters JSON Schema for agents.