Extract the best moments from MKV videos and turn them into shareable animated GIFs. Server-side processing handles even large files.
Upload Your Video
Drag and drop or click to browse
MP4, WebM, AVI, MOV, MKV, FLV & more • Up to 500MB
MKV (Matroska) is a popular container for high-quality video, often used for movies, TV shows, and screen recordings. While MKV supports virtually every codec, it isn't playable in most browsers or messaging apps. Converting MKV to GIF lets you pull out key scenes and share them as universally playable animations.
Upload your MKV file (up to 500 MB), trim to the exact scene you want, choose a quality preset, and convert. Our server runs FFmpeg, which decodes H.264, H.265, VP9, AV1, and the other codecs you find inside an MKV container. Processing is capped at two minutes, so trim before uploading rather than after.
Matroska has no MIME type in the HTML5 media stack and no browser compatibility row. WebM is derived from Matroska and plays everywhere, but MKV itself is not a web container. This matters because the editor loads your file into an HTML5 video element first, so you can scrub the timeline, set trim points, crop, and paint a mosaic mask before uploading. Our server converts MKV without any issue — we verified this through the live upload path — but whether you get a usable preview depends on your browser. Chrome will often play an MKV whose streams are H.264 or VP9 because it recognises the codecs despite the container; the same file carrying H.265 or an older codec usually will not. If the editor reports a load error, the file is not corrupt and the converter has not rejected it: the browser could not decode it, so it never reached the server. Remuxing to MP4 fixes this and is fast, because it copies the streams into a new container instead of re-encoding them.
This is specific to MKV and worth checking before you convert. Matroska allows many video, audio, subtitle, and metadata tracks in one file, and some releases genuinely carry two video tracks — a main feature plus a commentary angle, or a full-resolution stream alongside a smaller one. The editor reads dimensions from whichever track your browser exposes, while FFmpeg selects its own default track on the server. When those disagree, output is scaled to the dimensions the browser reported while the frames come from the track FFmpeg chose. We reproduced this with a file holding a 320x240 track followed by a 1280x720 track: the result was the 320x240 stream upscaled to 944x530, which looks soft rather than detailed. So if a converted GIF looks blurrier than the source should allow, a second video track is a likely cause. Checking the track list in a player such as VLC will confirm it, and remuxing to a single-video-track file resolves it.
GIF has no audio channel and no subtitle layer, so every audio and subtitle track in your MKV is dropped during conversion. Soft subtitles — the selectable kind stored as their own track — will not appear. If the dialogue matters, the subtitles need to be burned into the video before uploading, or you crop to a region where hardcoded subtitles are already part of the picture. This is also why a multi-gigabyte MKV can yield a modest GIF: most of that size was several audio languages and high-bitrate video you are not carrying forward.
For this kind of source, the palette matters more than the frame rate. Higher Quality runs at 24 fps with a full 256-colour palette and handles most scenes well. Best Quality runs at 30 fps and also builds its palette in a separate pass across every frame in the clip instead of sampling while encoding, which is what you want for gradients, night scenes, and skin tones where colour banding is the first thing you would notice. Keep those clips short, because 30 fps for ten seconds is 300 frames. Smaller File at 10 fps with 128 colours is fine for a quick reaction clip, and Smallest File at 5 fps with 64 colours should be reserved for content that is nearly static.
Browsers do not support Matroska as a container. Chrome sometimes plays an MKV whose streams are H.264 or VP9, but there is no guarantee, and H.265 or older codecs generally will not preview. Our server converts MKV fine — the failure happens at the browser preview step, before upload. Remuxing to MP4 copies the streams without re-encoding and takes seconds.
If the MKV carries more than one video track, the editor may report the dimensions of one track while the server decodes another. Output is then scaled to dimensions that do not match the frames, which reads as softness. We reproduced a 320x240 track being upscaled to 944x530 this way. Check the track list in VLC, and remux to a single-video-track file if there are two.
Not usefully. Processing is capped at two minutes, and GIF has no interframe compression, so a long clip produces a file no platform will accept. Trim to the few seconds that matter. For anything longer, a video file is the right format.
The video track only. Embedded subtitle tracks, audio tracks, and chapter markers are not carried into the GIF. Subtitles appear only if they were already burned into the video image.
Server-side, FFmpeg decodes H.264, H.265/HEVC, VP8, VP9, AV1, MPEG-2 and more. The narrower constraint is your browser, which has to decode the file for the preview and trim step before upload. That is why an MKV can convert correctly yet still fail to open in the editor.
No. Each preset targets a pixel budget and scales your source to fit, so a 4K input is reduced considerably. That is deliberate: a 4K GIF would be impractically large and no platform would accept it. At Best Quality a source of 720p or below keeps its native resolution, and larger sources are scaled down proportionally.