Converting video: the difference between rewrapping and re-encoding

By The Video Downloader team · 2026-09-09 · 5 min read

Converting a video means one of two very different things, and the word hides the distinction. Re-encoding decompresses the picture and compresses it again, which takes time and costs quality every single time it happens. Remuxing moves the existing tracks into a different container without touching them, which is fast and lossless. Almost every complaint about converted files being soft, slow to produce or oddly large comes down to a re-encode happening where a remux would have done. Here is how to tell them apart and when each one is unavoidable.

Re-encoding: rewriting every frame

Re-encoding takes the compressed picture apart and compresses it again, which means the encoder is making fresh decisions about what to throw away. Video codecs are lossy, so each pass discards detail that cannot come back, and doing it twice is worse than doing it once.

That is the generation loss problem, and it is easiest to see in audio because the chain is short enough to count. An MP3 made from a YouTube video runs original master, then YouTube's AAC or Opus encode, then your MP3 encode. Two lossy generations. Taking M4A instead keeps YouTube's AAC as it is, which is one generation and a smaller file. The audio guide works through that chain with the real stream bitrates.

Re-encoding is also slow, because every frame has to be decoded and encoded again rather than copied. A conversion that takes several minutes on a clip that downloaded in seconds is telling you exactly which operation it performed.

Every re-encode costs something. The only free conversion is the one that does not re-encode.

Remuxing: changing the wrapper, not the contents

Remuxing lifts the existing video and audio tracks out of one container and drops them into another without recompressing anything. The bytes that describe the picture are copied across unchanged, so the result is bit for bit as good as the source and it finishes almost instantly.

This works because a container is a wrapper, not a quality setting. MP4 holds a video track, an audio track and metadata, and the codec inside it is what compresses the picture. That distinction is the most repeated error in this whole subject, and the format guide takes it apart properly.

The catch is compatibility. You can only rewrap into a container that supports the codec you already have, and the target device still has to be able to decode that codec. Remuxing an AV1 stream into an MP4 does not make an old TV able to play AV1.

Which one happens on this site

Video downloads are assembled rather than re-encoded. On YouTube above 360p, the video and audio arrive as separate streams, and ffmpeg joins them into one MP4. That join copies both streams as they are, so the picture you get is the picture YouTube served, with no extra generation added.

That is why a download and a conversion feel so different in speed. The merge is a copy operation, so it finishes quickly, while a genuine re-encode would take much longer on the same file.

Audio is the one place a real re-encode happens, and only when you ask for MP3. YouTube serves AAC or Opus, and MP3 is neither, so producing an MP3 means encoding the audio again. Choosing M4A on the audio page avoids that step entirely by keeping the original AAC, which is why M4A is the technically cleaner choice wherever your player supports it.

When a re-encode is actually worth it

Only when compatibility or size forces your hand. If nothing needs to change, changing it costs quality for no benefit, which is the mistake behind most unnecessary conversions.

The compatibility case is real though. H.264 plays on every phone, TV, editor and old laptop, while VP9 has weak support in older versions of Premiere, DaVinci Resolve and iMovie, and AV1 has the worst compatibility on older hardware even though it is the most efficient. This tool prefers H.264 for exactly that reason, which means the file you download usually needs no conversion at all.

The size case is the other one. A smaller file always means less information, and the honest framing is that you are choosing to lose quality in exchange for space. If you are trying to predict how much space you would save, the measurements in the file size guide are a better starting point than guessing.

• Target device cannot decode the codec you have: re-encoding is the only route.
• File must fit a hard size limit: re-encoding, accepting the loss knowingly.
• You just want a different file extension: that is a rewrap, not a conversion, and it costs nothing.
• You want it to look better than the source: no conversion can do that.

What conversion cannot do, at all

It cannot add information that was never there. Upscaling a 720p file to a 2160p one produces a larger file with the same detail spread over more pixels, and encoding a 160 kbit audio source to 320 kbit MP3 produces a file roughly 2.4 times larger carrying exactly the same audio.

This is the mechanism behind the most oversold claim in the whole category. YouTube does not store audio above roughly 160 kbit, so a 320 kbit label describes the encoder setting and never the source.

The same applies to resolution. If the uploader never published a 2160p rendition, no downloader and no converter can create it, which the 4K guide explains in detail. The best possible outcome of any conversion is that it loses nothing, and the fastest way to get there is not to convert.

Frequently asked questions