Convert MTS to MP4

Turn AVCHD camcorder MTS and M2TS clips into MP4. The default mode copies the streams over untouched, with an automatic re-encode when it cannot.

🌐 Español

Drop your file here (.mts, .m2ts)

🔒 Private by design: your files are processed locally in your browser and never uploaded to any server.

Written and maintained by Last updated

AVCHD is a transport stream wearing a folder structure

MTS and M2TS are the file extensions behind AVCHD, the recording format Sony, Panasonic, Canon and others built consumer and prosumer camcorders around for well over a decade. What is inside is an MPEG transport stream, the same broadcast-oriented packaging used for digital television, chosen because it survives being written continuously to a card and cut off mid-recording without corrupting everything before it.

Copy footage off one of those cameras and you do not get a tidy list of clips. You get a directory tree, usually with the video buried several levels down in a folder called STREAM, holding files named 00000.MTS, 00001.MTS and onwards. The numbers are the order they were recorded in, and a single long shot is frequently spread across several of them because the camera starts a new file as it goes.

The frustration is that the video inside is often perfectly modern H.264, the very same codec sitting inside every MP4 on your phone. It is just wrapped in a container that Windows Explorer, macOS Finder, most players and a good number of video editors either refuse outright or handle badly. Nothing needs improving here. The wrapper needs changing.

Two modes, and the one condition that switches between them

  1. Drop your MTS or M2TS file on the box, or click Choose a file. Files copied straight out of an AVCHD folder tree work exactly as they are.
  2. Leave Conversion mode on Fast, keep original quality (recommended) unless you already know from a previous attempt that the result needs rebuilding.
  3. Click Convert MTS to MP4 and watch the percentage.
  4. Download the MP4 from the link, with the before and after sizes printed just above it.

Behind the default setting the tool tries a stream copy first: one video stream and one optional audio stream mapped across, no codec change, and the index moved to the front of the file so a player can start before the whole thing has been read. Not a single frame is decoded, which is why this finishes in a fraction of the time an encode would and why the picture is bit for bit what came off the camera.

What is worth understanding is how narrow the safety net under that attempt is. The copy runs in strict mode, so FFmpeg exiting with an error triggers the fallback, and a zero-byte result triggers it too. Those are the only two conditions. Any copy that completes successfully is handed to you, and the tool never inspects the result to ask whether it was a good idea. Choose the second mode and the attempt is skipped entirely and the re-encode runs from the start.

One video stream, one audio stream, nothing else survives

Both paths map the first video stream and, if there is one, the first audio stream. The question mark on that second mapping is what lets a silent clip through instead of failing on a missing track.

Everything else is dropped. A second language or commentary track, any subtitle stream, chapter markers and the auxiliary data an AVCHD folder tree keeps alongside the video all end at this step. For camcorder footage that is rarely a loss, since a home recording has one soundtrack and nothing else, but it is worth knowing before you convert an archive and delete the originals. If a clip carries something you care about beyond the picture and the first audio track, keep the source file.

The one thing that is added is the faststart flag, which moves the index to the front of the finished MP4. That costs nothing and makes the file behave properly when it is streamed rather than opened locally.

When Dolby audio comes through and your player shrugs

This is the failure the fast path can genuinely hand you, and it is worth recognising because it does not look like a failure. AVCHD camcorders commonly record Dolby Digital audio, and a stream copy moves that across as it is. Since the copy completed, no fallback fires. What you get is an MP4 whose picture plays anywhere and whose sound depends entirely on whether the player you opened it in can decode that audio inside this container. Some can and some cannot.

The fix is one run rather than any investigation. Switch to Re-encode to H.264 (maximum compatibility) and the audio is decoded and rewritten as AAC at 192 kbps, which nothing refuses. You pay for it in time and in a small, permanent loss on the soundtrack, and you get a file that behaves the same way everywhere.

If you only wanted the sound in the first place, there is a shortcut worth knowing: video to MP3 accepts .mts and .m2ts directly, so you can pull an audio track out of camcorder footage without converting the video at all.

What the compatibility mode spends its time on

Picking the second mode, or falling into it after a failed copy, means every frame is decoded and encoded again with x264 at a quality-targeted setting and a fast preset, plus the AAC audio pass. That is real work, it is proportional to the length of the clip, and it runs on a single thread inside your tab because the multi-threaded engine needs page headers this site cannot set without breaking its ad frames.

Two practical consequences. The first is that a failed fast attempt is not free: you pay for the attempt and then for the full encode after it. The second is that the result is a genuine re-encode, so it is a little softer than the original, permanently. Quality-targeted encoding keeps that small, but “maximum compatibility” is the honest name for the mode and “identical” is not on offer from it.

For the same two-mode arrangement applied to a different container, MKV to MP4 works the same way, tries the same copy first, and is the page to use for downloaded video rather than camcorder footage.

Working through a whole memory card

A card full of clips is the normal case rather than the exception, and there is no batch mode here: one file per run, drop, convert, download, repeat. That is a direct consequence of the encoder running on your own processor in a browser tab instead of on a server farm, where a queue of multi-gigabyte files would tie the page up with no way to see which one had failed.

Once the clips are MP4s, joining them is the natural next step, and Merge Videos is built for exactly this shape of job. It probes each file first and only stream-copies them together when the video codec, the dimensions, the frame rate and the audio codec all agree, which clips from one camcorder normally do, so a whole afternoon can usually be joined without a second encode. From there the rest of the video tools here handle trimming and rotation on a format everything already understands.

Frequently asked questions

My camcorder clip had 5.1 surround and a second audio track. Where did they go?

Only the first audio stream is carried over. Both modes map exactly one video stream and at most one audio stream into the MP4, so a second track, a commentary, any subtitle stream and the chapter data are all left behind by design. The channel layout inside the track that does survive is untouched on the fast path, so a 5.1 first track stays 5.1, but the compatibility mode re-encodes it to AAC.

How can I tell whether my clip took the fast route or was re-encoded?

Watch the two file sizes the page prints when it finishes. A stream copy lands in the same neighbourhood as the source, since the identical compressed frames are being repackaged and only the container overhead around them changes, so expect the second number to sit close to the first. A re-encode is choosing its own bitrate from scratch and usually lands somewhere visibly different. The clock is the other giveaway, because a copy of a large clip finishes in a fraction of the time an encode needs.

The picture plays but there is no sound in QuickTime. What went wrong?

Most likely nothing failed, which is the awkward part. AVCHD camcorders commonly record Dolby Digital audio, and the fast mode copies whatever audio it finds straight across without asking whether every player can decode it inside an MP4. The fallback only triggers when the copy itself cannot complete, not when it completes into something your player dislikes. Run the same clip again on the compatibility mode and the audio is decoded and rewritten as AAC, which nothing refuses.

My STREAM folder has thirty numbered files for one afternoon. Do I convert them all separately?

Yes, one run each, since this page takes a single file at a time. Camcorders split a long recording across numbered files as they go, so a continuous shot often arrives as several clips. Convert each one, then join the resulting MP4s with the Merge Videos page, which takes several files at once and can usually copy them together without another encode because clips off one card share a codec, a resolution and a frame rate.

My file is called .M2TS in capitals. Does the extension case matter anywhere?

No, in either place it is checked. The drop zone lowercases the extension before comparing it against the accepted list, and the module's own test for which of the two AVCHD extensions you brought is case insensitive too. All that test decides is what to call the file inside FFmpeg's workspace, so that the right parser is chosen for it. Uppercase, lowercase or mixed all behave identically.

Is there an upper limit on the size of clip this can take?

Nothing artificial, but there is a practical one. Your clip is written into a virtual filesystem inside the browser tab before any work starts, and on the fallback path that happens a second time for the retry, so the file has to fit in memory alongside the output being built. Camcorder files are commonly a couple of gigabytes each, which is usually fine on a desktop and less reliable on a phone. A run that dies on a very large file is nearly always this and not the format.

Related tools