MKV is best understood as a wrapper, not a quality setting. It can carry untouched audio and video, or it can carry streams that were already compressed with loss, so the extension alone tells you very little. The practical answer to is MKV lossless depends on the codec inside the file and on whether the tracks were copied or re-encoded.
The short answer in plain terms
- MKV is a container, so the file extension does not decide quality by itself.
- A remux to MKV can be lossless if the streams are copied without re-encoding.
- MKV can also store genuinely lossless codecs such as FFV1, FLAC, and PCM.
- If the source was already lossy, MKV does not restore lost detail.
- For quality, the codec and workflow matter far more than the wrapper.
What MKV actually is
I treat Matroska as a transport layer for media. It organises video, audio, subtitles, chapters, tags, and attachments in one file, but it does not decide how the picture or sound is compressed. That means the same .mkv extension can hold a lightly compressed archive master or a heavily compressed streaming encode.
That distinction matters because people often use “MKV” as if it were a codec. It is not. The codec is what creates or preserves losslessness; the container only stores the result. So an MKV file can be excellent for preserving a complex media package, but its extension tells you nothing about whether the image data itself is lossless.
Once that distinction is clear, the next question is whether the streams inside the container were preserved bit for bit.
When an MKV file is genuinely lossless
An MKV becomes genuinely lossless in two common cases: when the tracks inside are already lossless, or when you remux the file without re-encoding. In the second case, the samples are copied rather than decoded and encoded again, so the audio and video data stay the same. Matroska’s own documentation describes transmuxing in exactly that way: a lossless process that keeps the original data unaltered.
| Scenario | Lossless? | Why it matters |
|---|---|---|
| Blu-ray or camera footage copied into MKV with stream copy | Yes, for the copied streams | The packets are moved into a new container without being re-encoded. |
| MKV carrying FFV1 video and FLAC or PCM audio | Yes | The codecs themselves are designed to preserve the original data. |
MP4 to MKV with -c copy
|
Yes, for the streams that are copied | FFmpeg’s documentation treats this as copying without re-encoding. |
| Any file transcoded to a new codec | No, in practice | New compression decisions are applied, so the output is no longer identical to the source. |
The important takeaway is that losslessness belongs to the stream, not the extension. An MKV can preserve a lossless source perfectly, but it can also wrap a lossy source without changing anything about the underlying quality. That is useful, but it is not the same thing as making the file lossless.
So the next step is spotting where quality is actually lost in real workflows, because that is where most mistakes happen.

What makes an MKV file lossy
I see this mistake constantly: people convert to MKV and assume the conversion improved quality. It did not. If the video is encoded with H.264, H.265, AV1, or another lossy codec, the MKV file is still carrying a lossy stream. The container may be different, but the image data has already been compressed in a way that throws information away.
Loss can also appear the moment you re-encode during conversion. A resize, deinterlace, colour conversion, noise reduction pass, or simple codec change forces the frames to be rebuilt, which means the output is no longer a perfect copy of the source. Audio can suffer the same problem if you turn FLAC or PCM into AAC or MP3 just for convenience.
- Re-encoding changes the samples.
- Filtering usually forces re-encoding.
- Lossy source files stay lossy, even inside MKV.
- Metadata changes do not affect audio or video quality, but they can disguise what really happened.
That is why I never judge a file by extension alone. The wrapper can be pristine while the stream inside already carries compression loss. Once you separate the two, preserving quality becomes much easier to control.
How to keep quality unchanged when converting to MKV
If your goal is preservation, not re-creation, the workflow should be simple: remux first, encode only when you truly need to. The safest path is to copy the existing tracks into MKV and avoid filters or effects that would trigger a new encode. In practice, that means using stream copy rather than a full transcode.
ffmpeg -i input.mp4 -map 0 -c copy output.mkv
The point of that command is not the syntax itself; it is the behaviour. The -c copy part tells FFmpeg to copy streams without re-encoding, and -map 0 helps retain the full set of tracks. If you want subtitles, multiple audio languages, or chapters preserved as well, a remux is usually the right move.
- Check the source codecs before doing anything else.
- Use a remux or stream copy if you want the same samples preserved.
- Avoid filters unless you are deliberately changing the picture or sound.
- Verify the result with a media analyser such as MediaInfo or ffprobe.
If the source is already lossy, this still has value. You will at least avoid adding another generation of compression artefacts. That is not the same as making the file lossless, but it does protect the quality you already have, which is often the real goal in day-to-day video work.
From there, the natural question is whether MKV is actually the best container for the job, or just the most flexible one.
MKV versus other common containers
MKV is usually the most flexible choice when I care about multiple audio tracks, subtitles, chapters, and long-term compatibility with a wide range of codecs. That said, flexibility is not the same as universal playback support. For distribution, the best container depends on where the file will be used and who needs to open it.
| Container | Best for | Typical trade-off |
|---|---|---|
| MKV | Archiving, remuxing, mixed tracks, chapter support | Not every consumer device supports it equally well |
| MP4 | Broad playback compatibility and web delivery | Fewer container features and more codec restrictions |
| MOV | Editing pipelines and professional media interchange | Less convenient for general distribution |
| WebM | Web-focused delivery with a narrower codec set | Not as flexible for complex media packages |
The decision rule I use before choosing MKV
My rule is simple. If I want to preserve multiple tracks, subtitles, chapter markers, or a lossless master, MKV is a strong choice. If I need the smallest chance of playback friction on phones, browsers, or consumer devices, I check whether MP4 will serve the same purpose more safely.
For archival work, I prefer MKV with lossless codecs such as FFV1 for video and FLAC or PCM for audio. For simple format changes, I use MKV as a container only when I can keep the original streams untouched. And if I know the source is already lossy, I treat MKV as a clean wrapper, not as a quality upgrade.
The practical answer is that MKV itself is neither lossless nor lossy. It can preserve data perfectly, and it can also hold genuinely lossless codecs, but it can just as easily wrap a lossy encode. Read the codec, check the workflow, and treat the extension as the last clue, not the first.