How to Convert MPEG to MP4 (Free, Online, No Upload)

The fastest way to convert an MPEG file is PixelTools' [MPEG to MP4 tool](/convert-video/mpeg-to-mp4). Drop your `.mpg` or `.mpeg` file onto the page, let it process, and download the resulting `.mp4`. There's no account to create and no software to install — the conversion runs entirely in your browser using WebAssembly (ffmpeg.wasm), so the file never leaves your device. Both `.mpg` and `.mpeg` extensions are treated as the same underlying MPEG-1/MPEG-2 source format, so it doesn't matter which one your file has. Because MPEG-1/2 video isn't stream-copy compatible with an MP4 container, this conversion always does a full re-encode to H.264, which takes a bit longer than a simple repackaging job but guarantees the output plays everywhere H.264 does.

MPEG-1 and MPEG-2 are the video formats behind most DVD rips and pre-H.264 camcorder exports — for years they were a safe, standard choice. That changed as browsers, phones, and web uploaders converged on H.264 as the default video codec. Native MPEG-1/2 decoder support has quietly disappeared from most modern browsers and mobile devices, and most current software never bothered adding an MPEG-1/2 decoder in the first place, since H.264 covers nearly everything people need. The result is a file that used to open fine and now just fails silently, gets rejected on upload, or refuses to play at all — not because the file is corrupted, but because the software on the other end no longer knows how to decode it.

This tool runs ffmpeg.wasm — a WebAssembly build of the ffmpeg engine — directly in your browser tab, decoding your MPEG-1/MPEG-2 video and audio and re-encoding it as H.264 video inside an MP4 container. Unlike some other conversions PixelTools offers, this one can't take a fast stream-copy shortcut: MPEG-1/2's video codec simply isn't compatible with what an MP4 container expects, so a full re-encode is the only path. That means every conversion involves genuinely decoding and re-encoding the whole file, which is more CPU work and takes longer than a stream copy would. The upside is that the resulting MP4 uses H.264, the codec with by far the broadest playback support across browsers, phones, and editing software today.

Because the conversion happens entirely client-side, nothing about the video — its content, length, or metadata — is sent to a server at any point. That makes it a sensible option for old family camcorder footage or DVD rips you'd rather not upload to a third-party site just to get a playable copy. Since a full re-encode is always required, processing time depends mainly on the length of the source file and how fast your device's CPU is, as your own machine is doing all the decoding and encoding work rather than a remote server. There's no account requirement and no watermark added to the output — the MP4 you download is ready to use as-is.

Re-encoding to H.264 generally produces a much more efficient file than the original MPEG-1/2 source, but depending on the encoding settings and the length of the video, the resulting MP4 can still be larger than you'd like for emailing, uploading, or sharing. If that happens, run the converted file through [PixelTools' video compressor](/compress-video) afterward to bring the size down further. Keeping these as two separate steps — convert first, then compress if needed — keeps each tool focused on doing one job well, rather than trying to guess the right compression settings during the format conversion itself.

If you'd rather not use a browser tool, there are a couple of offline options:

ffmpeg (command line): `ffmpeg -i input.mpg -c:v libx264 output.mp4` decodes the MPEG-1/2 source and re-encodes it to H.264, the same fundamental approach the browser tool takes.

VLC: Many builds of VLC can play MPEG-1/2 files directly even when other software can't, and VLC's Convert/Save feature can also export a copy in a different format.

For a one-off conversion with no setup or installation required, an online tool is generally the quicker path, especially since a full re-encode is unavoidable either way.