Premiere Pro won't import MKV — remux it, don't re-encode it

Premiere Pro refuses MKV on purpose: Adobe removed MKV import in CC 2019 build 13.1.3 and has not put it back since, so the container is rejected whatever is inside it.

The correct fix is a remux, not a transcode. An MKV holding H.264 and AAC becomes a Premiere-native MP4 in seconds, with the compressed video bytes copied across untouched. HandBrake cannot do that — it always re-encodes.

Why Premiere refuses MKV files

A video file is two separate things: a container and the codecs stored inside it. MKV (Matroska) is the container — the index that says where each frame starts, which tracks exist, and how they line up in time. H.264, HEVC, AAC and AC-3 are codecs: the actual compressed picture and sound.

Premiere's importer is written against a list of containers it trusts. MKV is not on that list, so the file never gets far enough for Premiere to look at the codec inside. That is why the dialog is so unhelpful — depending on your version you get File format not supported or Unsupported format or damaged file, and neither tells you that the H.264 stream inside is something Premiere would happily cut all day.

Adobe's reasoning at the time was that these were transcode and download formats rather than camera-original ones. Whether or not you agree, the consequence is fixed: the container has to change before Premiere will look at the file.

Remux the container, don't re-encode the pixels

A remux reads the compressed frames out of the MKV and writes the identical bytes into an MP4 index. The picture is bit-for-bit the same file you started with. It is not "high quality" — it is the same quality, because no pixel was ever decoded and re-compressed.

A transcode decodes every frame back to raw pixels and compresses them again. That is a generation of loss before you have made a single edit, and your Premiere export then adds a second one. On gradients, motion and small text you will see it, and worse again after YouTube re-compresses the upload.

This is the single reason the usual forum advice is wrong. "Just run it through HandBrake" turns a job that should take seconds into one that runs at least as long as the clip itself, and costs quality you cannot get back. If you want the longer argument with the settings that matter, the guide on converting MKV to MP4 without losing quality covers what to do when a copy genuinely is not available, and there is a broader comparison in the browser-based HandBrake alternative write-up.

How to remux an MKV to MP4

The MKV to MP4 converter on this site runs FFmpeg compiled to WebAssembly inside your own browser tab. Your file is not uploaded — there is no server to upload it to — which matters if the footage is a client's, under NDA, or simply not yours to hand to a third party.

1. Drop the MKV onto the page. It reads the header locally and shows the container, video codec and profile, resolution, frame rate, duration and audio codec.
2. Read the line that says what it is about to do. If it says the streams will be copied, you are getting the lossless path. If it says the video will be re-encoded, jump to the next section before you press anything.
3. Convert, and save the MP4 next to the original. Keep the MKV until the edit is finished.
4. Import the MP4 into Premiere as normal.

Two limits worth knowing before you start. Files over 2 GB are refused outright — a 32-bit WebAssembly heap cannot address them — and above roughly 300 MB the page warns you that it wants about three times the file size in free memory. A long OBS session will often be bigger than 2 GB, and in that case the browser is not the right tool for the job; use a desktop remuxer such as FFmpeg or MKVToolNix locally.

When your MKV cannot be copied

MP4 is a stricter container than MKV. Matroska will hold almost any codec ever shipped; MP4 has a much shorter list of things ordinary players and editors will accept from it. So a copy is available when the MKV contains:

• H.264 video — copies, and Premiere is completely at home with it.
• HEVC (H.265) video — copies, and current Premiere versions import HEVC in an MP4, though long-GOP HEVC is heavier to scrub than H.264 on any machine.
• AAC, MP3 or AC-3 audio — copies.

It is not available when the MKV holds VP9 or AV1 video, or Opus, Vorbis, FLAC or PCM audio. Those are legal in Matroska and not usefully playable from an MP4, so the tool re-encodes and tells you so. VP9 and AV1 are common in files pulled from the web; H.264 is what a screen recorder or a disc rip almost always gives you. If you are not sure which you have, you can check the codec inside a video file without converting anything.

One edge case catches people out. If your MKV carries AC-3 audio and you copy it straight into the MP4, some tools decode it and some do not. If Premiere shows the video but the audio track is silent or missing, convert again with the audio option set to re-encode — the video still copies, so you lose nothing visually. The same symptom on a finished export is covered in the guide on video that plays but has no sound.

Never just rename the extension

Half the forum threads tell you to rename recording.mkv to recording.mp4. Do not do this.

The extension is a label. It changes nothing inside the file, which is still a Matroska file with Matroska headers. What you get is one of three outcomes: Premiere still refuses it, Premiere imports it and behaves unpredictably later in the edit, or — worst — it appears to work, you cut for two hours, and the project turns unstable at export with errors that point nowhere near the real cause. A remux takes seconds and produces a genuinely valid MP4. There is no reason to gamble a project on a filename.

OBS recordings: frame rate and extra tracks

If your MKV came out of OBS, a screen recorder or a game capture, there is a second problem that a remux does not fix. Screen recorders usually write variable frame rate — they only emit a frame when the picture changes, so a still slide costs almost nothing. Premiere assumes a constant frame rate, so a VFR file drifts: audio and video start together and are visibly out of sync by the end of a long take.

A container change cannot repair that, because the timing is a property of the frames themselves. Fixing it requires a re-encode to a constant frame rate, which is exactly what the guide on converting variable frame rate to constant frame rate walks through. The signature is simple: sync is fine at the start of the clip and wrong at the end. If sync is wrong from the first frame, it is a different problem.

The other thing to check is your track layout. OBS can record microphone and desktop audio as separate tracks, and MKV is happy to carry all of them. A conversion here keeps only the first video and first audio stream — extra audio tracks and any subtitle tracks are dropped, and the tool says so before it starts. If you need those tracks separately in Premiere, either set OBS to record them as separate files, or demux them locally with MKVToolNix before you convert.

What this cannot do

Two honest limits. First, this converter cannot produce ProRes, DNxHR or any other intermediate editing codec — the browser build does not contain those encoders. If your workflow calls for transcoding to an edit-friendly mezzanine format, do that inside Premiere's media browser or with a desktop encoder; the remux to MP4 is the step that gets the footage in the door, not a substitute for a proxy workflow.

Second, if the MKV is on a phone rather than your edit machine, the Video Converter app for iPhone and its Android version will convert it there — but they always re-encode with the phone's hardware encoder and have no stream-copy mode. They suit long or 4K footage where a browser would crawl, not a lossless container change.

And if you landed here after a different editor rejected a file, the causes rarely transfer: Resolve fails for its own reasons, covered in the guide on DaVinci Resolve refusing to import MP4.