Video

How to Convert Videos Without Losing Quality

Published Mar 19, 2026 7 min read By ChangeThisFile Team

Quick Answer

Truly lossless video conversion is only possible when changing containers without changing codecs (e.g., MKV to MP4 with H.264 — called remuxing). When you must re-encode, use CRF 18 for visually lossless quality, avoid re-encoding more than once, never upscale resolution, and keep the original file as your master.

Let's start with the uncomfortable truth: most video "conversion" involves re-encoding, and re-encoding always loses some quality. Every time compressed video is decoded and re-compressed, information is permanently discarded. There is no way around this — it's a fundamental property of lossy compression.

But "some quality loss" ranges from "literally invisible" to "looks like it was filmed through a dirty window." The difference comes down to understanding when conversion is truly lossless, when re-encoding is unavoidable, and how to preserve maximum quality when it is. This guide gives you the specific settings and strategies.

When Conversion Is Truly Lossless: Remuxing

There is exactly one scenario where video conversion is 100% lossless: remuxing. This means moving the compressed video and audio streams from one container format to another without decoding or re-encoding them. The data is bit-for-bit identical before and after.

Remuxing works when the target container supports the same codecs as the source. The most common example:

MKV to MP4: Both support H.264 video + AAC audio. If your MKV contains these codecs, the conversion is a remux — takes seconds, zero quality loss, output file is roughly the same size.
MOV to MP4: MOV and MP4 are closely related containers (both based on Apple's QuickTime format). H.264/AAC content remuxes perfectly.
MP4 to MKV: Works in reverse too. MKV accepts virtually any codec.

How to know if you'll get a remux: check the codec of your source file. If the source uses H.264 video and AAC audio, and your target is MP4/MKV/MOV, it's almost certainly a remux. If the source uses DivX, Xvid, or VP9 and your target is MP4, re-encoding is required because MP4 doesn't natively support those codecs.

When Re-encoding Is Unavoidable

You must re-encode when:

Codec incompatibility: AVI (DivX/Xvid) to MP4 — the old codec isn't supported in the new container.
Resolution change: Downscaling 4K to 1080p requires decoding every frame, resizing it, and re-encoding.
Bitrate reduction: Shrinking a 20 Mbps file to 5 Mbps requires re-encoding at the lower rate.
Format-specific requirements: MP4 to WebM requires transcoding from H.264 to VP9 or AV1 because WebM doesn't support H.264.
Editing or trimming: Frame-accurate cuts (not on keyframes) require re-encoding at least the affected frames.

Re-encoding is not catastrophic. At high quality settings, the loss from a single re-encode is invisible to the naked eye. The problem is cumulative: each generation of re-encoding degrades further. A video re-encoded 5 times looks noticeably worse than one re-encoded once. This is generation loss, and it's why you should always re-encode from the original source, never from a previously converted copy.

Quality Preservation Strategies

When re-encoding is unavoidable, these settings minimize visible quality loss.

Use CRF Mode (Not Target Bitrate)

CRF (Constant Rate Factor) targets a quality level rather than a specific bitrate. The encoder uses whatever data is needed to achieve that quality — more for complex scenes, less for simple ones. This produces better results than targeting a fixed bitrate.

CRF values for H.264 (FFmpeg's libx264):

CRF	Quality	File Size vs Source	Use Case
0	Mathematically lossless	5-10x larger	Archival masters (impractical for distribution)
18	Visually lossless	~70-100% of source	Best practical quality — indistinguishable from source
23	Good (FFmpeg default)	~30-50% of source	General purpose, good balance
28	Acceptable	~15-25% of source	Mobile viewing, social media
35+	Low quality	Very small	Thumbnails, previews

Each +6 CRF roughly halves the file size. The sweet spot for quality-conscious conversion is CRF 18-20. You won't see the difference from the source, and the file size is reasonable.

For H.265 (libx265), the scale is the same but equivalent quality is about 4-6 CRF points higher. CRF 24 in H.265 looks roughly like CRF 18 in H.264, at a significantly smaller file size.

Two-Pass Encoding for Target File Sizes

When you need a specific file size (e.g., "this must fit in a 25 MB email attachment"), two-pass encoding is better than single-pass at a fixed bitrate. The first pass analyzes the entire video, mapping scene complexity. The second pass distributes bits based on that analysis — giving more to complex scenes and less to simple ones.

Two-pass takes twice as long but produces visibly better results at the same file size compared to single-pass CBR. Use this when file size is the constraint rather than quality.

Handle Audio Separately

Audio is only 5-15% of most video files, so compressing it aggressively saves almost nothing while degrading the listening experience. When re-encoding video, you have two options for audio:

Copy the audio stream: If the audio codec is compatible with the target container (e.g., AAC audio going into an MP4), copy it without re-encoding. Zero audio quality loss, negligible size impact. In FFmpeg: -c:a copy
Re-encode at high bitrate: If you must re-encode audio (e.g., AC3 surround from an MKV to stereo AAC for MP4), use at least 192 kbps for stereo, 384 kbps for 5.1 surround. These bitrates are generous for AAC and the file size cost is minimal.

Resolution: Never Upscale, Downscale Thoughtfully

Upscaling does not improve quality. Converting 720p to 1080p adds 2.25x more pixels by interpolation — the encoder literally makes up pixel values that weren't in the source. The result is a bigger file that looks identical (or slightly softer) than the original 720p. The extra pixels contain zero new detail. Don't do it.

Downscaling can be useful. Reducing 4K to 1080p for a specific use case (social media, messaging, limited storage) is a valid strategy. At the same bitrate, 1080p will look sharper than 4K because each pixel gets more data. The key is to pair the resolution with an appropriate bitrate:

1080p: 5-8 Mbps for good quality, 8-12 Mbps for high quality
720p: 2.5-5 Mbps for good quality
480p: 1-2.5 Mbps for good quality

A common mistake: downscaling to 720p but keeping the original 20+ Mbps bitrate. You end up with a 720p file that's larger than a well-encoded 1080p file. Always reduce bitrate proportionally when reducing resolution.

What Gets Lost Besides Video Quality

Re-encoding can strip more than just visual quality. Depending on your tool and settings, you may also lose:

Subtitles: Embedded subtitle tracks (SRT, ASS) are often dropped during conversion unless explicitly mapped. MKV files commonly have multiple subtitle tracks; MP4 supports fewer subtitle formats.
Chapter markers: Useful in long videos (films, lectures). Not all converters preserve these.
Multiple audio tracks: MKV files from Blu-ray rips often have commentary tracks or multiple language tracks. Most converters extract only the first audio stream by default.
Timestamps and metadata: File creation date, camera metadata, GPS coordinates, rotation flags. These live in the container metadata and may not transfer between formats.
HDR data: HDR10 and Dolby Vision metadata requires codec support. Converting HDR content to SDR-only codecs strips the dynamic range information, often producing washed-out colors.

If any of these matter to you, check the output file after conversion before deleting the original.

Practical Scenarios: What to Do

"I Need to Share on WhatsApp/iMessage"

WhatsApp compresses videos heavily regardless of what you upload. There's limited value in sending a pristine file — it'll be re-encoded to roughly 1-2 Mbps H.264 anyway. Optimize for fast upload instead:

H.264 in MP4 container
720p resolution (WhatsApp will downscale 1080p anyway on most phones)
CRF 24-26 or 2-3 Mbps target bitrate
AAC audio at 128 kbps

A 1-minute clip at these settings is roughly 15-25 MB. Fast to upload, looks identical after WhatsApp's compression.

"I Need to Upload to YouTube"

YouTube re-encodes every upload into H.264, VP9, and AV1 at multiple resolutions. Your original file is discarded. The strategy is simple: upload the highest quality you have. Don't pre-compress "to save upload time" — you're just giving YouTube's encoder less data to work with.

Keep original resolution (don't downscale)
H.264 at CRF 18 or ProRes if you have it
MP4 or MOV container
AAC audio at 320 kbps or higher

YouTube recommends 8 Mbps for 1080p and 35-45 Mbps for 4K uploads. Uploading at higher bitrates is fine — more data gives YouTube's encoder a better source to work from.

"I Need to Play on My TV"

Most smart TVs support H.264 in MP4 and MKV containers. If your file won't play, the issue is usually the codec, not the container. Check the codec first:

H.264 in MKV? Remux to MP4. No quality loss, takes seconds.
VP9 or AV1? Older TVs may not decode these. Re-encode to H.264. Newer TVs (2020+) usually handle VP9; 2022+ handle AV1.
HEVC/H.265? Most TVs from 2016+ support it. If yours doesn't, re-encode to H.264 at a higher bitrate to compensate for H.264's lower compression efficiency.

USB playback has additional constraints: some TVs limit USB playback to specific codecs or file sizes. When in doubt, H.264 + AAC in an MP4 file plays on virtually every TV manufactured in the last decade.

"I Need to Reduce File Size"

Ordered by impact, from most effective to least:

Switch to a more efficient codec: H.264 → H.265 can save ~50% at the same quality. This has the biggest impact but requires re-encoding and the target device must support H.265.
Reduce resolution: 4K → 1080p cuts pixel count by 75%. Combined with proportional bitrate reduction, this can shrink files by 3-4x.
Lower CRF / bitrate: Increasing CRF from 18 to 23 roughly halves file size with moderate (often invisible) quality loss.
Reduce frame rate: 60fps → 30fps halves the frame count. Acceptable for non-action content. Don't reduce below 24fps.
Trim unnecessary content: Cut intros, outros, and dead air before converting. No quality loss from cutting on keyframes.

Combining strategies: converting a 4K H.264 file at CRF 18 (say, 15 GB per hour) to 1080p H.265 at CRF 24 can produce a file around 1.5-2 GB per hour — a 7-10x reduction with quality that looks great on a laptop or phone screen.

Generation Loss: Why You Should Never Re-encode Twice

Every re-encode is a generation. The original recording is generation 0. First re-encode is generation 1. Each generation loses information that cannot be recovered. The first generation might be invisible. By generation 3-5, you'll notice softness, blocking artifacts, and color banding — especially in gradients and fine textures.

Practical rules:

Always re-encode from the original source file, never from a previously converted copy.
Keep the original as your master. Store it on an external drive if disk space is tight, but don't delete it.
If you need multiple output formats (MP4 for web, WebM for embedding, 720p for mobile), encode each one from the original — not from each other.
If you must re-encode a re-encode (original lost), use CRF 18 or lower and accept that quality will be slightly worse than the source you're working from.

The best video conversion is the one that doesn't re-encode at all. Check if your conversion is just a container change — if so, it's a fast, lossless remux. When re-encoding is necessary, use CRF 18-20 for transparent quality, keep the original, and never chain re-encodes. Those three rules prevent 90% of quality problems people experience with video conversion.

Convert now: MKV to MP4 (usually lossless remux), AVI to MP4, MOV to MP4, or MP4 to WebM — free, no signup, at ChangeThisFile.

Key Takeaways

Truly lossless conversion only happens when remuxing (container change, same codecs). MKV-to-MP4 with H.264 is a common example.
CRF 18 is visually lossless for H.264. Use it when quality is the priority and file size is secondary.
Never upscale resolution — it makes files bigger without adding detail. Downscale thoughtfully with proportional bitrate reduction.
Copy the audio stream when possible instead of re-encoding it. Audio is a tiny fraction of file size.
Always re-encode from the original source, never from a previously converted copy. Generation loss compounds.
For YouTube uploads, send the highest quality you have. YouTube will re-encode it regardless.

Frequently Asked Questions

Is converting MKV to MP4 lossless?

Usually yes. If the MKV contains H.264 video and AAC audio, the conversion is a remux — the compressed data is moved to the MP4 container without any re-encoding. This is bit-for-bit identical and takes seconds. The only time it's not lossless is when the MKV contains codecs that MP4 doesn't support (e.g., VP9 or certain subtitle formats), requiring re-encoding of those specific streams.

What CRF value should I use in FFmpeg?

For H.264: CRF 18 for visually lossless quality, CRF 23 for a good balance of quality and size (FFmpeg's default), CRF 28 for smaller files with visible but acceptable quality loss. For H.265: add roughly 4-6 to these numbers for equivalent visual quality (CRF 22-24 is visually lossless). Each +6 CRF approximately halves the file size.

Will converting MP4 to WebM lose quality?

Yes, because MP4 typically uses H.264 while WebM requires VP9 or AV1, meaning the video must be re-encoded. However, VP9 and AV1 are more efficient codecs than H.264, so at the same visual quality the WebM file will often be smaller. Use a high quality setting (CRF 18-20 for VP9) to make the loss imperceptible.

How do I know if my video was remuxed or re-encoded?

Check the conversion time and output file size. A remux completes in seconds regardless of video length and produces a file nearly identical in size to the original. A re-encode takes minutes to hours (proportional to duration and resolution) and typically produces a different file size. You can also compare the codec info of both files — if input and output use the same codec, it was likely a remux.

Can I convert 4K to 1080p without losing quality?

Any resolution change requires re-encoding, which technically loses some quality. However, 1080p at a good bitrate (5-8 Mbps H.264, or 3-5 Mbps H.265) looks excellent on 1080p displays. You're discarding resolution detail that wouldn't be visible on the target screen anyway. The key is using a bitrate appropriate for 1080p — don't pair 1080p resolution with a 4K-level bitrate (wasteful) or a 480p-level bitrate (looks bad).

Should I use H.264 or H.265 for converting?

H.264 if compatibility matters — every device, browser, and player supports it. H.265 if file size matters — roughly 50% smaller at the same quality, but playback support is less universal (no Firefox without OS support, some older smart TVs and media players can't decode it). For archival or personal use where you control the playback device, H.265 is the better choice. For sharing publicly, H.264 is safer.

Does trimming a video cause quality loss?

It depends on where you cut. Cutting on keyframes (I-frames) can be done without re-encoding — the data between keyframes is intact. Cutting at an arbitrary timestamp between keyframes requires re-encoding at least a few frames around the cut point. Most video editors handle this automatically. For a long video where you're cutting large sections, the re-encoded portion (a few frames at each cut point) is negligible.

Why does my re-encoded video have worse colors?

This usually happens when HDR content is converted without preserving HDR metadata, or when the color space changes during conversion (e.g., BT.2020 to BT.709). The result is washed-out, flat-looking video. If your source is HDR, either keep it in an HDR-compatible format and codec, or apply a proper HDR-to-SDR tone mapping during conversion rather than letting the encoder silently drop the metadata.

Ready to convert your files?

Use ChangeThisFile to convert between 600+ formats — free, fast, and private.

Start Converting