Free Video Format Converter

Containers, codecs, and what conversion actually changes

Most file extensions name a container, not a codec. A .mp4 file is a wrapper that holds a video track plus an audio track plus metadata. The video track might be encoded with H.264, H.265, VP9, AV1, or several others. The audio track might be AAC, MP3, Opus, or FLAC. Converting between containers (MP4 to MKV, for example) doesn't necessarily re-encode anything if both containers accept the same codecs; FFmpeg can do it in seconds via stream copy. Converting between codecs (H.264 to VP9, for example) requires re-encoding every frame from scratch, which is slow and lossy. This tool detects what's needed and chooses the cheaper path when possible.

Why containers exist: MP4 (ISO/IEC 14496-14) was designed for streaming and indexing, with fast seek tables and support for many codecs, playing everywhere. WebM (Google, 2010) is a subset of Matroska restricted to royalty-free codecs (VP8/VP9/AV1 plus Opus/Vorbis) for the open web. MOV (Apple QuickTime, 1991) is MP4's predecessor and the native macOS format; ProRes editing footage almost always lives in MOV. MKV (Matroska) is the open Swiss Army knife: handles arbitrary codecs, subtitle tracks, chapter markers, attachments; common for ripped Blu-rays and anime. AVI is the Microsoft legacy from 1992, weak metadata, mostly seen with old DivX/Xvid encodes.

Why conversion sometimes fails: renaming a .mov to .mp4 doesn't actually change anything inside the file. If your iPhone exported HEVC video, a Windows 10 device without the HEIC/HEVC media extensions will reject it regardless of the extension. Real conversion has to re-encode the video stream into a codec the target accepts. This tool defaults to H.264 plus AAC for MP4 output, the most universally compatible combination available.

How this tool works under the hood

Same engine as the video compressor: FFmpeg compiled to WebAssembly via Emscripten by Jerome Wu starting in 2019. The browser-side binary is roughly 30 MB, runs entirely in the tab via SharedArrayBuffer multi-threading (requires Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp headers, which this site sets). When you drop a video, the file is read into the WebAssembly virtual filesystem via a streaming reader.

Behind the scenes the tool runs commands like -i input.mov -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k output.mp4 for MOV-to-MP4 conversion. For container-only changes where the codec is already correct (for example, converting an MKV file that already contains H.264 plus AAC to MP4), the tool uses -c copy for a near-instant stream-copy operation that just rewrites the container without re-encoding. The choice happens automatically based on probing the input file.

Codec selection per format: MP4 output uses H.264 video plus AAC audio (universal). WebM output uses VP9 video plus Opus audio (open and modern). MKV output uses H.264 plus AAC by default but can carry anything Matroska supports. AVI output uses MPEG-4 Part 2 video plus MP3 audio (legacy compatibility). The tool picks the right codec/container pair so the receiving player won't reject the file.

Brief history of video containers

• QuickTime / .MOV, 1991. Apple ships QuickTime with System 6. The .MOV container becomes the standard format for Mac multimedia and the eventual basis for MP4.
• AVI, 1992. Microsoft ships AVI (Audio Video Interleave) as part of Video for Windows. The format predates modern codec features: no proper subtitle support, weak metadata, no streaming-friendly index. Still seen with legacy DivX/Xvid encodes and old screen recordings.
• MP4 ratified, 2001. ISO/IEC 14496-14 formalizes MP4 as the MPEG-4 Part 14 container, based heavily on QuickTime MOV. Combined with H.264/AVC (ratified 2003), MP4 plus H.264 plus AAC becomes the universal video file by the late 2000s.
• Matroska, 2002. Open-source flexible container designed to handle anything: arbitrary codecs, subtitle tracks, chapter markers, attachments. Becomes the format of choice for Blu-ray rips, anime fansubs, and long-form archival.
• WebM launches, 2010. Google launches WebM as an open royalty-free alternative to MP4. Restricted to VP8/VP9/AV1 video plus Vorbis/Opus audio. Designed to ship with HTML5 video without patent licensing concerns.
• Browser-side conversion matures, 2019 to 2026. Jerome Wu publishes the first ffmpeg.wasm in 2019. By 2024 the 4.x line stabilizes at around 30 MB with SharedArrayBuffer multi-threading. Browser-side video conversion becomes practical for files up to 1 to 2 GB, replacing many cloud-based services for personal use.

How It Works

1. Upload your video: Click to select or drag and drop a video file in any common format (MP4, WebM, AVI, MOV, MKV).
2. Choose output format: Select the target format and optionally adjust quality settings, resolution, and codec.
3. Convert and download: Click Convert and download the output video file when processing is complete.

Why Use Video Converter?

Video formats fragment across platforms, MP4 plays everywhere, WebM is optimized for web, MOV is the Mac standard, and MKV is common for high-quality video. When a video won't play on a device or upload to a platform, converting it to the right format solves the problem instantly. This browser-based converter handles the most common format conversions without requiring software installation or file uploads to external servers.

Features

• Multiple formats: Convert between MP4, WebM, OGG, and other web-compatible video formats.
• Quality control: Adjust output bitrate and quality settings to balance file size and video quality.
• Resolution options: Downscale to standard resolutions (1080p, 720p, 480p, 360p) to reduce file size.
• Audio preservation: Audio tracks are retained in the converted output by default.
• Browser-based: Video processing happens locally using WebAssembly, your videos never leave your device.

Real-world conversion workflows

• Compatibility fixes. An iPhone exports HEVC video. A Windows 10 friend can't play it. Converting to MP4 plus H.264 fixes it instantly. The most common reason to convert.
• Platform upload requirements. Some upload forms accept only .mp4. Some social platforms re-encode whatever you send but require certain containers. Converting before upload avoids rejected uploads and reduces server-side re-encoding artifacts.
• Web embedding. Self-hosted video on a website typically uses MP4 for the HTML video tag. Modern sites also serve a WebM fallback for slightly better compression on supporting browsers. Converting an original master to both MP4 and WebM is a standard step.
• Legacy archive rescue. Old AVI/DivX clips from a 2005 hard drive, Flash FLV files from a defunct streaming service, .RM RealMedia files from the 1990s. Converting to MP4 makes them playable on modern devices and ensures they survive future format obsolescence.
• Preparing footage for editing. DaVinci Resolve, Premiere, and Final Cut all have preferred codecs for editing. Converting an iPhone HEVC clip to ProRes or H.264 MOV before importing reduces decode load and improves timeline scrubbing performance.
• Sharing via channels with format limits. Some corporate email gateways block MKV or AVI attachments by content-type filtering. Converting to MP4 sidesteps these blocks. Same for some chat clients that auto-preview MP4 but show MKV as a generic file.

Common pitfalls and what they mean

• Renaming the extension does nothing. Changing example.mov to example.mp4 in your file manager doesn't re-encode the file. If the codec inside isn't supported by the target player, it still fails. Real conversion has to re-encode or re-mux the actual stream.
• Subtitle tracks get dropped. Soft subtitles (SRT, ASS, PGS, VobSub) embedded in MKV files typically don't survive conversion to MP4 by default. The tool would need explicit configuration to copy or burn-in the subtitle track. If you need subtitles preserved, use a desktop tool with explicit subtitle handling.
• Chapter markers and metadata vanish. Blu-ray-style chapter markers, embedded thumbnails, and rich metadata like director/cast info are typically lost in browser-side conversion. The output container has only the video and audio tracks.
• Alpha channel flattens to black. ProRes 4444, HEVC with alpha (Apple variant), and VP9 with alpha can carry transparency. Converting to standard H.264 MP4 silently flattens transparency to a black background. For motion graphics, use ProRes 4444 in MOV or stay in WebM with VP9 alpha.
• HDR-to-SDR conversion needs tone-mapping. A 10-bit HDR clip (Dolby Vision, HDR10) converted to 8-bit SDR without explicit tone-mapping produces washed-out or weirdly saturated output. Tone-map on the source device before conversion or use a desktop tool with HDR support.
• Container compatibility isn't codec compatibility. An MP4 file with H.265 video plays fine on a 2026 phone but fails on a 2015 Windows laptop. The container is fine; the codec inside isn't. Always pair the right codec with the right container for your audience.

Privacy: your video never leaves your device

CloudConvert, Convertio, FreeConvert, Zamzar, OnlineConvertFree and many others all use the same pipeline: upload the full file, server runs FFmpeg, you download the result. A 200 MB phone video means 200 MB up and 50 to 200 MB back through their infrastructure. Video content commonly includes faces, locations, audio of conversations, screen recordings of private interfaces, GPS-tagged scenes. Most operators publish privacy policies committing to delete uploads in 1 to 24 hours and encrypt in transit; major ones hold ISO/IEC 27001 certifications. They have strong business reasons to honor those policies. But "deleted within an hour" is not "never seen." During that window the file sits on operator infrastructure, accessible to any process or person with the right permissions, visible in logs and backups per the operator's retention policy.

This tool never uploads anything. The full pipeline (file selection, decoding via browser-native readers, conversion via ffmpeg.wasm WebAssembly, download via the browser's blob API) runs inside your browser tab. No uploads, no network requests carrying video data, no log entries. You can verify by opening browser dev tools on the Network tab before converting: no requests leave with video content. Only the initial page load and the one-time roughly 30 MB ffmpeg.wasm download (cached for subsequent visits) hit the network. Put the browser in airplane mode after page load and the converter still works on local files.

When another tool is the right pick

• Files over 2 GB. Browser memory limits become a wall above roughly 2 GB. Use desktop HandBrake or FFmpeg CLI, which can stream from disk and use all available system RAM.
• Preserving subtitles, chapters, alpha. Use desktop FFmpeg with explicit -map flags, MKVToolNix for Matroska-to-Matroska remuxing with full track control, or Subler/MetaX on macOS for chapter and metadata handling. Browser-side conversion is for the simple case.
• Editing intermediate codecs. Final Cut Pro, Avid, DaVinci Resolve and Premiere want ProRes, DNxHD, DNxHR, or Cineform for smooth timeline editing. Browser tools can't produce these codecs (they're licensed and not in ffmpeg.wasm builds). Use the editing app's native conversion (Compressor for FCP, Media Encoder for Premiere) or FFmpeg CLI with prores_ks/dnxhd encoders.
• Converting hundreds of files. A shell script with FFmpeg CLI or a Python script using subprocess is dramatically faster than running a browser tool 100 times. Can also use GPU encoders for 10 to 20x speedup.

Frequently Asked Questions

What video formats are supported?

The tool supports conversion between MP4 (H.264/AAC), WebM (VP8/VP9/Opus), OGG (Theora/Vorbis), and other web-compatible formats. Support for AVI, MOV, and MKV depends on browser capabilities via the WebCodecs API.

Why is conversion slow for large videos?

Video conversion is computationally intensive. Large files (above 500 MB) or high-resolution video (4K) may take several minutes. The conversion runs in your browser using WebAssembly, so speed depends on your device's CPU.

Will I lose quality when converting?

Any conversion between lossy codecs (like H.264 to VP9) involves some generation loss. Converting at high bitrate settings minimizes visible quality loss. For lossless archival, use the highest quality setting or a lossless codec if available.

Other frequently asked questions

Can I just rename the file extension?

No. The extension is metadata for the operating system but doesn't change the actual encoded bytes inside. A .mov renamed to .mp4 is still encoded in the original codec, which may or may not be playable in the target environment. Real conversion has to re-encode (or re-mux) the actual stream.

Will quality drop?

Stream-copy conversions (when the codec doesn't change, only the container) are lossless: the bits are copied verbatim into the new wrapper. Re-encoding conversions (when the codec changes) introduce one generation of quantization noise; the output is visually close to but mathematically different from the input. Avoid converting the same file multiple times through codec changes; each round adds another generation of loss.

Should I pick MP4, WebM, AVI, or MKV?

MP4 for sharing to anyone on anything. WebM for web embedding where you want better compression and don't mind dropping Safari pre-2024 compatibility. MKV for archival with subtitles and chapter markers preserved. AVI only if a legacy system specifically requires it. Default to MP4 when in doubt.

Why is conversion slower than playback?

Decoding video is computationally light (your phone does it in real time at low power). Encoding video is computationally heavy: the encoder has to search for the best way to compress each frame, which is orders of magnitude more work than decoding. A 5-minute clip can take 5 to 20 minutes to encode at good quality on a typical laptop CPU. Hardware encoders (NVENC, QuickSync, VideoToolbox) are 10 to 20x faster but require desktop apps; browser tools can't access them.

Is there a desktop or command-line equivalent?

Yes, several. HandBrake (free, cross-platform GUI, uses the same FFmpeg under the hood). FFmpeg CLI is the canonical command-line tool. MKVToolNix for Matroska-specific operations. Subler for MP4 metadata on macOS. All produce essentially identical output to this browser tool because they share the same underlying engine.

Will EXIF/metadata survive conversion?

Most of it doesn't. Container-only conversion (stream copy MKV to MP4 for example) preserves a fair amount; codec re-encoding typically drops embedded thumbnails, GPS tags, and arbitrary metadata keys. If your workflow depends on metadata preservation, use a desktop tool with explicit metadata mapping flags (FFmpeg's -map_metadata 0 plus -movflags use_metadata_tags).