Free video converters

Containers and codecs, in plain terms

A video file is really two things folded together: a container and one or more codecs. The container is the box, the file format that holds the video track, the audio track, and anything else such as subtitles or metadata, and tells a player where each one starts and stops. The codec is what actually did the compressing: the mathematics that turned raw picture and sound into the much smaller stream of data sitting inside that box. A file with the extension .mp4 is a container; whether the video inside it is H.264 or HEVC is a separate, codec-level question.

MP4 (MPEG-4 Part 14) is based on the ISO base media file format, a structure that itself grew out of Apple's QuickTime format, the same family MOV belongs to; that shared ancestry is why MOV and MP4 files sit so close to each other in practice. MKV is the file extension for Matroska, an open container format designed from the outset to hold pretty much any combination of video, audio and subtitle tracks. WebM is a further profile of Matroska, one deliberately narrowed down to a small set of codecs built for the open web: VP8 or VP9 or AV1 for video, Vorbis or Opus for audio.

Confusing the two levels is the single most common cause of a subtitle track vanishing, an unplayable file, or a conversion tool refusing a file it should handle. Renaming a file's extension does not change its codec, and "this container plays everywhere" does not mean every codec that container can technically hold plays everywhere too. Knowing which question you are actually asking, container or codec, is most of what you need to pick the right conversion.

Why some conversions take seconds

Some conversions on this page finish almost as fast as the file can be read off disk, while others visibly grind through the whole video frame by frame. The difference is whether the tool has to re-encode anything, or whether it can simply repackage what is already there.

When the video and audio inside a file are already encoded in formats the destination container can hold, converting between containers is a remux: the compressed video and audio streams are copied across, byte for byte, into the new container's structure, without ever being decoded back into raw pixels and decompressed again. Nothing is recompressed, so nothing is lost and there is very little work to do, which is why a remux-only conversion can finish in well under a second for a file that would take minutes to re-encode.

A container conversion becomes slow the moment re-encoding is required instead: the source has to be fully decoded to raw frames, then compressed again from scratch in the target codec, frame by frame, for the entire length of the clip. That is genuinely heavy computational work, and it is why converting, say, a WebM file that uses VP9 into an MP4 that needs H.264 takes noticeably longer than converting an MP4 that is already H.264 into another MP4. Each tool checks which situation applies to your file before it starts, and tells you which one you are getting.

When a file has to be re-encoded

Re-encoding happens whenever the codec already inside a file is not one the destination container is allowed to hold, or not one your browser can produce. For MP4, that means H.264 or HEVC video paired with AAC or MP3 audio can usually be copied straight across; anything else, VP9 or AV1 video, or Opus or Vorbis audio, has to be decoded and re-encoded into a codec MP4 can actually contain, which needs your browser to decode it; if it cannot, the converter says so before you start.

Re-encoding is lossy whenever the source codec is itself lossy, which almost all common video and audio codecs are. Decoding a lossy stream back to raw frames and samples, then compressing it again, cannot recover detail the first pass of compression already threw away, and the second pass then makes its own compromises on top. The practical effect is usually small for a single conversion done at a sensible quality setting, but it is a real, permanent step down, not a like-for-like swap, which is worth knowing if a file might need converting more than once.

None of this is a defect to work around: it is simply what re-encoding is. The alternative, refusing to convert anything that cannot be copied without re-encoding, would make a converter far less useful than one that is upfront about the trade-off and applies it only when it has to.

MP4, WebM or GIF: which to choose

MP4 is the safest general-purpose choice: it is the format the widest range of devices, editing software and platforms expect by default, which makes it the right target whenever a file needs to go somewhere you do not fully control.

WebM is the container built specifically for the open web: an open, royalty-free format, and one a browser can often encode natively using its own built-in codecs rather than a licensed one. (Verified against the WebM Project's own description, webmproject.org/about, 22 September 2026.) It is a reasonable choice when a file is staying inside a web context, such as a page that will play it back directly, but it is not guaranteed to open in the same range of desktop and mobile software that MP4 does.

GIF sits in a different category entirely: it is not a video format at all in the codec sense, but an image format extended into short animated loops. Each frame in a GIF is limited to a palette of 256 colours, and the format carries no audio track whatsoever, so a GIF is only the right choice for a short, silent, looping clip, a reaction, a UI demo, a preview, never for anything where sound or full colour fidelity matters. For everything else, MP4 or WebM with a real video codec inside it is the better fit.

Compressing a video without wrecking it

Compression is a set of trade-offs, not a single dial: the size a video file ends up at is driven mainly by its resolution, its bitrate, and how long it runs for, and pushing any one of those down brings the file size down with it. The question worth asking before compressing anything is which of those you can afford to give up the least.

Dropping resolution, encoding a source down to 1080p or 720p rather than keeping it at its original size, tends to be the most visually forgiving way to cut a file down, since most viewing surfaces are smaller than the source footage anyway. Lowering bitrate at a fixed resolution keeps every pixel but gives the encoder less data to describe each frame with, which shows up first as softness in detail and motion rather than an obvious defect, and becomes more visible the further it is pushed. Aiming at a target file size, working out the bitrate that will fit a given duration into a size budget, is really the bitrate trade-off run in reverse: the same shrinking happens, just driven by a size limit instead of a quality preference.

There is no setting that avoids the trade-off altogether: a smaller file is a file with less data describing the same picture, and the only real choice is which part of the picture that missing data gets taken from.

Getting the audio out of a video

Pulling the audio out of a video file, for a podcast clip, a voiceover reference, or just to send someone the sound without the picture, means encoding the audio track on its own into a dedicated audio format such as MP3, discarding the video entirely.

MP3 is itself a lossy codec, so the encoding step involves the same trade-off as any other lossy compression: a higher bitrate keeps more of the original audio detail and takes up more space, a lower one saves space at the cost of some fidelity, most noticeable on complex material like music rather than plain speech. For most spoken-word use, a mid-range bitrate is more than adequate; music and mixed audio generally benefit from sitting higher up that range.

Extracting audio only works, of course, when the video actually has an audio track to extract in the first place; a silent source clip, or one that was captured or exported without sound, has nothing for an audio extractor to pull out, and the tool says so rather than producing an empty or broken file.

Browser support and very large files

Everything on this page runs inside your own browser rather than on a server, which means what a given browser can encode varies from one to the next and changes over time. Rather than assuming, each tool checks what your specific browser can actually produce before it starts, and tells you which output you are getting: an MP4 with H.264 video when your browser can encode it, or a WebM with VP9 video as a fallback when it cannot.

File size has its own limit, set by what a browser can safely hold and process in memory rather than by anything the tool itself imposes. Above 2 GB, a conversion is still attempted but flagged as likely to be slow and memory-hungry; above 4 GB, the file is refused outright rather than risking a browser tab that runs out of memory partway through.

Because everything happens on your device, your file, its name and its contents never leave it. If you accept analytics, we record only a rough size band, a rough length band, the output format and the outcome, such as whether the file converted without re-encoding; our privacy notice sets this out. The trade-off for that is the practical ceiling above: a server has effectively unlimited memory to throw at a huge file, a browser tab does not, and the 4 GB cutoff exists because of that difference rather than as an arbitrary restriction.

Questions about video converters

Do I need to install anything to convert a video?

No. Every converter on this page runs in your browser using your device's own processing power; there is nothing to install and no software to keep updated.

Is there a limit on how big a file I can convert?

Files above 2 GB carry a warning that conversion may be slow and memory-hungry; files above 4 GB are refused outright, since a browser tab only has so much memory to work with safely.

Will converting my video lose quality?

It depends on whether the file has to be re-encoded. When the source codec can be copied straight into the new container, nothing is re-compressed and nothing is lost; when re-encoding is required, it is a lossy step like any other, though usually small at a sensible quality setting.

Are my videos uploaded to a server?

No. Every conversion runs locally in your browser: your file, its name and its contents never leave your device. If you accept analytics, we record only a rough size band, a rough length band, the output format and the outcome, as our privacy notice explains.