How to Convert Video Files Without Losing Quality

Almost everyone hits the same wall eventually. A camera produces a MOV file that the editing software refuses to open. A client sends an AVI recorded in 2009. A website upload form rejects anything that is not MP4. A phone records a beautiful clip that turns into a blurry mess the moment it goes through a converter. Video conversion looks like it should be a one click problem, and yet the results swing wildly between perfect and unusable depending on settings most people never see.

The gap between a good conversion and a bad one is almost never the tool. It is understanding what the tool is being asked to do. Video files are not single objects. They are packages with several layers, and a conversion can touch one layer, two layers, or all of them. Touch the wrong layer and you throw away picture information you can never get back. Touch only the layer you need and the output can be pixel for pixel identical to the input while still solving your compatibility problem.

This guide walks through the whole picture. It explains what actually sits inside a video file, what each setting really controls, how quality loss accumulates, and how to pick settings for the specific place your video is going. By the end you should be able to look at any video file and know exactly what to do with it.

Containers and Codecs Are Not the Same Thing

This is the single most useful thing to understand about video, and it explains most of the confusion people run into. A video file has two separate identities. There is the container, which is the box, and there is the codec, which is the compression method used for the contents of the box. The file extension tells you about the box. It tells you almost nothing about what is inside.

Think of the container as a shipping crate. The crate has a label on the outside (MP4, MOV, AVI, MKV, WebM) and it holds several items: one video stream, usually one or more audio streams, and often subtitle tracks, chapter markers, timecode, camera metadata, and a thumbnail. The container defines how those items are stored side by side and how a player finds them. It also defines how quickly a player can jump to the middle of a file, which is why some containers stream well over the internet and others do not.

The codec is the compression algorithm applied to the video stream itself. H.264, H.265, VP9, AV1, ProRes, and DNxHD are codecs. The codec is where all the real work happens. It is the thing that decides how many megabytes a minute of footage takes and how much visual detail survives the trip.

The consequence is that two files both ending in .mp4 can be completely different animals. One might hold H.264 video and AAC audio, which plays anywhere. Another might hold H.265 video and Opus audio, which some older televisions and browsers refuse to touch. Both are valid MP4 files. The extension lied to you about compatibility, because the extension was never the thing that determined compatibility in the first place.

The containers you will meet

Notice that the weaknesses are almost all about acceptance rather than quality. MKV is a technically excellent container. It is simply not what a job application portal or an Instagram upload expects. That distinction matters, because it points to the cheapest possible fix for a large share of video problems: change the crate, leave the contents alone.

Rewrapping versus re-encoding

When you change only the container and copy the existing video and audio streams into it untouched, the operation is called rewrapping or remuxing. It is genuinely lossless. Not lossless in the marketing sense, but lossless in the arithmetic sense: the compressed picture data in the output is bit for bit identical to the input. Nothing is decoded, nothing is re-compressed, nothing is estimated. It also finishes almost instantly, because the computer is essentially copying bytes rather than analysing images.

Re-encoding is the other operation. The encoder decodes every frame back into raw pixels, then compresses them again using the target codec and settings. This is what allows you to shrink a file, change resolution, change frame rate, or move to a codec the source did not use. It is also where quality goes to die if the settings are wrong, because lossy compression always discards something.

Any time you face a conversion, the first question worth asking is whether a rewrap would solve it. A MOV file from an iPhone usually contains H.264 or H.265 video. If your problem is only that a website wants MP4, the correct answer is a rewrap, not a full re-encode. You keep every bit of quality and you finish in seconds instead of minutes.

Choosing a Target Codec for Where the Video Is Going

Once you know a re-encode is unavoidable, the next decision is which codec to encode into. This is a compatibility decision far more often than a quality decision, because at sensible bitrates all of the modern codecs look fine. What separates them is where they play. For a fuller background on how these formats are built, see the video file formats and compression guide.

H.264, also called AVC. Released in 2003 and still the most widely supported video codec ever made. Every browser, phone, television, console, and editing suite decodes it. It is not the most efficient codec available today, but it is decoded in dedicated hardware on practically every device, which means smooth playback and low battery drain. If you do not have a specific reason to choose something else, choose H.264. It is the reason MP4 with H.264 and AAC is the default answer to almost every sharing question.

H.265, also called HEVC. The successor to H.264, offering roughly 40 to 50 percent better compression at the same visual quality. A 1080p clip that needs 10 Mbps in H.264 may look equally good at 6 Mbps in H.265. The catch is licensing and support. Newer iPhones record in H.265 by default, yet many older browsers, some Windows installations, and a number of social platforms still handle it poorly. It is excellent for storage and archiving. It is risky as a delivery format when you do not control the playback device.

VP9. An open codec developed by Google, used heavily by YouTube and supported natively in Chrome, Firefox, and Edge. Efficiency sits between H.264 and H.265. It lives almost exclusively inside WebM containers. If your video is going on a website you control and you want small files with good quality, VP9 in WebM is a strong choice.

AV1. The newest mainstream codec, royalty free, and more efficient than H.265. Support is growing quickly in browsers and newer hardware, but encoding is slow and older devices cannot decode it in hardware, which drains battery and can stutter. Excellent for the future, still early for general use.

ProRes and DNxHD. These are editing codecs, sometimes called intermediate or mezzanine codecs. They compress lightly, produce very large files, and are designed so that an editing program can jump to any frame instantly without decoding a long chain of preceding frames. Never deliver in these formats, and never convert a delivery file into them expecting a quality improvement. Upconverting a compressed file to ProRes gives you a large file that looks exactly as bad as the small one it came from.

Why codec choice changes file size so dramatically

Video compression works by exploiting the fact that consecutive frames are mostly the same. Only a handful of frames, called keyframes, are stored as complete pictures. Everything between them is stored as a description of what changed. A newer codec is better at describing those changes compactly. It can search a larger area for matching blocks, it can split the picture into more flexible shapes, and it can predict motion more accurately.

This is also why a static presentation recording compresses to almost nothing while a handheld clip of falling leaves stays enormous. When nearly every pixel changes every frame, there is very little for the codec to reuse. Understanding this makes bitrate decisions far more intuitive, because you stop thinking in terms of a fixed number and start thinking in terms of how much motion the footage contains.

Bitrate, Resolution and Frame Rate

These three numbers determine both file size and perceived quality, and they interact. Getting them right is most of the battle in any conversion.

Resolution is the pixel grid: 1920 by 1080, 3840 by 2160, and so on. It sets the ceiling on how much fine detail can exist. Reducing resolution is the bluntest and most effective way to shrink a file, because pixel count scales with the square of each dimension. Halving both width and height cuts the pixel count to a quarter.

Frame rate is how many pictures per second. Thirty is standard for general video, twenty four is the cinematic look, sixty is used for sport, gaming, and smooth motion. Doubling frame rate roughly needs a fifty to sixty percent bitrate increase to hold the same quality, not a full doubling, because consecutive frames at higher frame rates are more similar to each other.

Bitrate is how many bits per second the encoder is allowed to spend. This is the setting that most directly controls quality. Too low and you see blocking, smearing, and banding. Too high and you waste storage without any visible benefit.

Practical bitrate targets for H.264

For H.265 or VP9, you can take roughly 60 percent of these numbers and expect similar quality. For AV1, roughly 50 percent. These are starting points, not laws. The honest test is always to encode a thirty second sample and look at it at full size on a good screen.

Estimating the file size before you convert

File size in megabytes is approximately bitrate in megabits per second, multiplied by duration in seconds, divided by eight. A five minute clip at 9 Mbps works out to 9 times 300 divided by 8, which is about 338 megabytes, plus a small amount for audio. Audio at 128 kbps adds roughly 4.5 megabytes over five minutes, which is usually negligible next to the video.

This formula is worth memorising because it lets you work backwards. If an upload form caps you at 100 megabytes and your clip is three minutes long, you have 100 times 8 divided by 180, which is about 4.4 Mbps of total budget. Subtract a little for audio and you know that 720p is a realistic target and 1080p at 60 frames per second is not.

Constant rate factor versus target bitrate

Many encoders offer two modes. Target bitrate mode tells the encoder to hit a specific average, which is what you want when you have a hard size limit. Quality mode, often labelled CRF or constant rate factor, tells the encoder to maintain a consistent visual quality and spend whatever bitrate that requires. CRF generally produces better results per megabyte, because it spends bits on the difficult scenes and saves them on the easy ones instead of applying the same budget everywhere.

On the common CRF scale, lower numbers mean higher quality. Around 18 is close to visually lossless for H.264, 23 is a sensible default, and 28 starts showing visible artefacts on detailed footage. If your tool offers a simple quality slider rather than numbers, the same logic applies: pick the highest setting that still meets your size requirement.

What Generation Loss Is and Why It Matters

Every lossy re-encode discards information permanently. Convert a file once and the loss is usually invisible. Convert the output again, then again, and the damage compounds in a way that becomes obvious surprisingly fast. This is generation loss, and it is the main reason video that has been passed between five people looks so much worse than the original.

The mechanism is straightforward. The first encode makes decisions about which details to discard, introducing small errors around edges and in flat areas. The second encode treats those errors as real image content and tries faithfully to preserve them, spending bits on compression artefacts instead of on picture. It then adds its own new errors on top. Each pass makes the image slightly noisier from the encoder point of view, and noise is expensive to compress.

Three practical rules follow from this:

• Always work from the highest quality version you have access to. Going back to the camera original and doing one conversion beats doing three conversions on an already compressed copy.
• Do all your changes in a single pass. If you need to trim, resize, and change format, do them together rather than as three separate exports.
• Prefer rewrapping over re-encoding whenever the codec inside is already acceptable. Zero generations of loss beats one.

Keep an untouched master copy of anything that matters. Storage is cheap and re-encoding is irreversible. Once the detail is gone, no tool, no upscaler, and no amount of sharpening brings it back. Sharpening in particular creates the illusion of detail by exaggerating edges, which usually makes a compressed video look worse rather than better.

Converting MOV, AVI and WebM to MP4

MP4 is the destination for most conversions because it is the format everything accepts. The right approach depends entirely on where the file came from.

MOV to MP4 is the easiest case and the most common. QuickTime MOV and MP4 are close relatives, both descended from the same underlying file format specification. A MOV recorded on an iPhone, a Canon, or a Sony almost always contains H.264 or H.265 video with AAC or PCM audio, which are all valid inside MP4. The conversion is usually a pure container change with no picture loss at all. When people complain that converting MOV to MP4 ruined their video, the cause is nearly always a tool that re-encoded at a low default bitrate rather than anything inherent to the formats. If you regularly need to move footage off Apple devices into software or upload forms that insist on MP4, a browser based MOV to MP4 converter handles the job without installing anything or uploading your footage to a server.

AVI to MP4 is a genuine conversion. AVI is an old container from 1992 and the video inside is typically an older codec such as DivX, Xvid, MJPEG, or uncompressed frames. None of those can simply be copied into MP4, so re-encoding is unavoidable. The important thing here is to avoid making the result worse than it needs to be. Old AVI footage is often 640 by 480 or 720 by 576 at fairly low bitrates. Do not upscale it. Keep the original resolution, keep the original frame rate, and use a generous quality setting so the encoder does not add a second layer of damage on top of the first.

WebM to MP4 also requires re-encoding, because WebM holds VP8, VP9, or AV1 and MP4 conventionally holds H.264 or H.265. This comes up constantly with screen recordings made in a browser, video downloaded from web based tools, and files exported from certain online editors. Since VP9 is more efficient than H.264, converting to H.264 at the same visual quality will produce a noticeably larger file. That is expected and correct. Trying to match the original file size will cost you quality.

A note on audio during conversion

Audio streams have their own compatibility rules and they get overlooked constantly. MP4 expects AAC. WebM expects Vorbis or Opus. If a converted file plays with picture but no sound, an incompatible audio codec is nearly always the reason. Re-encoding audio to AAC at 128 to 192 kbps is cheap in both file size and processing time, and it eliminates an entire category of playback problems. Unlike video, audio re-encoding at sensible bitrates is very hard to hear.

Frame rate conversion is worth avoiding

Changing frame rate between values that are not simple multiples produces judder, because the converter must invent or discard frames on an uneven schedule. Going from 60 to 30 is clean, because every second frame is simply dropped. Going from 30 to 24 is not, because the ratio is awkward and motion develops a subtle stutter that is difficult to unsee once noticed. Unless a platform specifically demands a particular frame rate, keep whatever the source has.

When WebM Is the Right Answer

Most conversion advice pushes everything towards MP4, but there is one important case where the opposite is true. If you are putting video on a website you control, particularly a background video, a product demonstration, a looping hero clip, or a short explainer, WebM with VP9 is frequently the better format.

The reason is bandwidth. Every browser released in the past decade supports VP9 in WebM, and VP9 typically delivers the same visual quality as H.264 at 30 to 40 percent smaller file size. On a page where a video is the largest asset, that difference directly changes how fast the page feels and how it scores on Core Web Vitals. Video is very often the single heaviest element on a modern web page, and cutting it by a third is a larger performance win than almost any other optimisation available.

The standard professional approach is to serve both. An HTML video element can list several source files and the browser picks the first one it understands, so you list WebM first and MP4 second. Modern browsers take the small efficient file, older ones fall back safely, and nobody sees a broken player.

<video autoplay muted loop playsinline>
  <source src="/demo.webm" type="video/webm">
  <source src="/demo.mp4" type="video/mp4">
</video>

Producing that WebM version is a single conversion step from your existing MP4 master. If you are optimising a site and want the smaller file without setting up encoding software, an MP4 to WebM converter gives you the second source file in a couple of minutes.

The one place to avoid WebM is anywhere you do not control playback. Social platforms, email attachments, messaging apps, presentation software, smart televisions, and most video editors either reject WebM outright or handle it unpredictably. Use it for the web, use MP4 for everything else.

Shrinking File Size Without Wrecking Quality

Size limits drive an enormous share of video conversions. Email attachments cap out around 25 megabytes. Messaging apps compress aggressively above their own thresholds. Upload forms have hard ceilings. Learning file size reduction properly means knowing which lever to pull first, because the levers are not equally costly.

The levers, roughly in order of best value for the quality you give up:

1. Trim the length. Free in quality terms and completely linear in effect. Removing thirty seconds of dead air at the start of a two minute clip cuts a quarter of the file. Nothing else is this efficient. Do this first, every time.
2. Drop resolution to match how it will be viewed. A video that will be watched in a small embedded player or on a phone gains nothing from 4K. Going from 2160p to 1080p typically cuts the file by 60 percent or more and is invisible on any screen smaller than a large monitor.
3. Lower the bitrate deliberately. Going from 12 Mbps to 8 Mbps at 1080p is usually imperceptible on general footage. Going to 3 Mbps is not.
4. Switch to a more efficient codec. H.265 or VP9 buys you a large reduction for free in quality terms, at the cost of some compatibility.
5. Reduce frame rate. Effective but visually obvious on motion. Sixty to thirty is often acceptable. Below twenty four, movement starts looking wrong.
6. Reduce audio bitrate. Rarely worth it. Audio is a small fraction of the total and bad audio is far more noticeable to viewers than a slightly soft picture.

That last point deserves emphasis because it contradicts most people intuition. Audiences tolerate mediocre video far better than they tolerate mediocre audio. Given a hard size budget, protect the sound and let the picture take the hit.

For the everyday case of a file that is simply too large to send, working directly with a video compressor is faster than reasoning about codecs. You set a target, preview the result, and adjust if it went too far. Because the processing happens in your browser rather than on a remote server, the footage never leaves your computer, which matters for anything confidential.

Two pass encoding

When you have a strict size target, two pass encoding is worth the extra time. In the first pass the encoder analyses the entire video and records where the difficult scenes are. In the second pass it distributes the bitrate budget according to that map, spending more on the complex moments and less on the simple ones. The result is meaningfully better than single pass encoding at the same file size, particularly on footage that mixes static and fast moving scenes. The cost is roughly double the encoding time.

Why some videos refuse to get smaller

Occasionally a file resists compression no matter what you try. The usual culprits are film grain, sensor noise from low light recording, confetti or rain, rapidly changing lighting, and fine repeating patterns such as brick walls or striped clothing. All of these mean high frequency detail that changes constantly, which is the worst case for any codec. A mild noise reduction filter before encoding can help considerably in these situations, because it gives the encoder less random information to preserve.

Pulling the Audio Out of a Video

Not every conversion is video to video. A large share of real world tasks are actually about extracting the sound: turning a recorded interview into an audio file for transcription, saving a lecture for listening during a commute, lifting music or a voiceover out of a clip, or archiving a podcast recording without carrying the video weight around.

This is one of the cheapest operations in video work. The audio stream inside a video file is already a separate, independently compressed stream. Extracting it does not require decoding a single video frame. When the source audio is already AAC or MP3, the extraction can copy the stream directly with no quality loss whatsoever, and the resulting file is often less than one percent of the original size.

A one hour 1080p recording might be 2 gigabytes. The audio inside it is likely 50 to 60 megabytes. If all you need is the conversation, carrying the other 1.95 gigabytes around is pure waste, and it makes the file harder to email, slower to upload to a transcription service, and more expensive to store. Converting a recording with video to MP3 gives you a file you can play on anything, scrub through quickly, and hand to a transcription tool without a long upload.

A practical detail: for spoken word content, 96 to 128 kbps mono is genuinely enough and halves the size again compared with stereo. Reserve 192 kbps and above for music, where stereo imaging and high frequency detail actually matter.

Choosing Settings for Each Destination

The correct settings depend on where the video is going. Here is a practical reference for the most common destinations.

YouTube and long form video platforms

Upload the highest quality file you reasonably can. YouTube re-encodes everything it receives, so whatever you send becomes the source for their compression. Giving them a heavily compressed file means their encoder works from damaged material and the result is visibly worse. Upload 1080p at 12 to 15 Mbps or 4K at 40 to 50 Mbps in MP4 with H.264, and let the platform handle the rest. Do not try to pre optimise for their bitrate. You are not saving anyone bandwidth, you are only adding a generation of loss.

Instagram, TikTok and short form vertical video

Vertical 1080 by 1920, 30 frames per second, MP4 with H.264 and AAC. These platforms compress hard, so keep the source clean and avoid tiny text or thin lines, both of which fall apart under aggressive compression. Keep files under about 100 megabytes to avoid additional processing on upload. Match the exact aspect ratio rather than letting the app crop for you.

Email and messaging

Aim for under 20 megabytes to stay safely under the common 25 megabyte limit. For a two to three minute clip, that means 720p at around 1 Mbps, which is soft but perfectly watchable for informal content. For anything longer or anything where quality matters, upload it somewhere and send a link instead. Fighting a 25 megabyte limit with a ten minute video is a losing battle.

Websites and landing pages

WebM with VP9 as the first source, MP4 with H.264 as the fallback. Keep background and hero videos under about 3 megabytes and under 10 seconds. Mute them, loop them, and add the playsinline attribute so mobile browsers do not force fullscreen. Always set a poster image so something meaningful appears while the video loads.

Presentations and offline playback

MP4 with H.264 at a moderate bitrate, embedded rather than linked. Presentation software is notoriously fussy about codecs, and a video that plays perfectly on your laptop can fail on the conference room machine. H.264 in MP4 is the only combination worth trusting here. Test on the actual playback device if you possibly can.

Archiving

Keep the camera original untouched if storage allows. If you must compress for archival, H.265 at a high quality setting preserves nearly everything at roughly half the size. Store a plain text note alongside the files recording what was done, because in five years you will not remember which copy was the master.

Common Conversion Problems and How to Fix Them

Most video problems fall into a small number of recognisable patterns.

The video plays but there is no sound. An audio codec the player does not support, or an audio stream that was dropped during conversion. Re-encode the audio to AAC.

Audio drifts out of sync over time. Usually a variable frame rate source, which is common with screen recordings and phone footage. The fix is to convert to a constant frame rate. Drift that increases steadily through the file is the signature of this problem, as opposed to a fixed offset which indicates a simple delay.

The output is far larger than the input. The target bitrate is higher than the source needed. Check the original file bitrate first and aim at or below it. Encoders cannot restore detail that was already discarded, so extra bits go nowhere useful.

The picture looks blocky or smeared. The bitrate is too low for the resolution and motion in the footage. Either raise the bitrate or lower the resolution. Lowering resolution at a fixed bitrate almost always looks better than keeping a high resolution starved of bits.

Colours look washed out or oversaturated after conversion. A colour range mismatch between limited range (16 to 235) and full range (0 to 255), or an HDR source being converted to a standard range output without proper tone mapping. HDR footage from recent phones converted carelessly produces notably flat, grey looking results.

The video is rotated or upside down. Phone video stores orientation as metadata rather than in the pixels. Some conversions drop that metadata, leaving the raw sideways footage. The fix is to apply the rotation physically during conversion rather than relying on the flag.

The file will not play on one specific device. Almost always a codec support issue rather than a corrupt file. Re-encode to H.264 in MP4 with AAC audio, which is the closest thing to a universal format that exists.

A Practical Conversion Workflow

Putting it all together, here is a sequence that avoids the common mistakes.

1. Identify what you actually have. Check the container, the video codec, the resolution, the frame rate, and the bitrate. Most players show this in a file information panel. Every later decision depends on these five numbers.
2. Define the destination precisely. Which platform, which device, what size limit, what format is accepted. Vague goals produce vague settings.
3. Ask whether a rewrap is enough. If the codec inside is already acceptable and only the container is wrong, rewrap and stop. You are finished with zero quality loss.
4. Trim before anything else. Remove dead space at the start and end. This is free size reduction and it also shortens every subsequent processing step.
5. Set resolution to match the viewing context. Not higher, since it is wasted, and never higher than the source, since upscaling adds size without adding detail.
6. Choose bitrate from the tables above, adjusted for how much motion your footage contains. Use quality mode when there is no hard size cap.
7. Do everything in one pass. Combine trimming, resizing, and format changes into a single export rather than chaining separate operations.
8. Check a thirty second sample before committing to a long encode. Look at the most detailed and fastest moving part of the clip, since that is where problems appear first.
9. Verify on the target device. A file that plays on your machine has not been tested. Confirm it works where it is actually going.
10. Keep the original. Always. The converted file is disposable, the master is not.

Privacy and Browser Based Conversion

One consideration that is easy to overlook: where does the file go while it is being converted? Traditional online converters upload your video to a server, process it there, and give you a download link. That means your footage sits on someone else infrastructure, subject to their retention policy, their security, and their terms of service. For a holiday clip that may not matter. For an unreleased product demonstration, a recorded medical consultation, an internal company meeting, or anything covered by a confidentiality agreement, it matters a great deal.

Browser based conversion works differently. The processing happens locally using the video capabilities already built into your browser, and the file never travels across the network at all. There is no upload wait, no download wait, and no copy of your footage on a remote machine. For large files this is also simply faster, because uploading a 2 gigabyte video on a typical home connection takes longer than converting it.

The tradeoff is that processing uses your own computer resources, so a long 4K file will take a while and will make the fans spin. For the overwhelming majority of everyday conversions, that tradeoff is clearly worth it.

Frequently Asked Questions

Does converting a video always reduce quality?

No. A container change with stream copying, such as rewrapping MOV into MP4 while keeping the same H.264 video, is mathematically lossless. Re-encoding is lossy, but at a sufficient bitrate the loss is not visible under normal viewing conditions. The reputation conversion has for ruining video comes from tools that quietly re-encode at low default settings.

Can I improve the quality of a low quality video by converting it?

No. Detail that was discarded during the original compression does not exist in the file anymore. Converting a 480p video to 1080p produces a larger file containing the same amount of real information, just stretched. AI upscaling tools can generate plausible detail, but they are inventing it rather than recovering it, and the results can look artificial on faces and text.

Should I use H.265 instead of H.264?

Use H.265 when you control playback and want smaller files, such as personal archives or storage on your own devices. Use H.264 when the file is going to other people, to a platform, or to an unknown device. The efficiency gain is real, but a file nobody can open has no value regardless of how efficiently it was compressed.

Why does my phone record in MOV or HEVC instead of MP4?

Apple devices default to MOV containers and, on recent models, H.265 video, because it halves storage use for the same quality. It is an excellent default for the phone itself and an inconvenient one for sharing. Most iPhones offer a most compatible setting in the camera options that switches recording to H.264, which is worth enabling if you frequently move footage onto other systems.

What is the maximum quality setting I should use?

There is a point beyond which extra bitrate produces no visible improvement, and it arrives sooner than most people expect. For 1080p H.264, going above about 20 Mbps for typical footage is wasted. The reliable method is to encode short samples at two or three settings and compare them at full size. If you cannot tell the difference, take the smaller file.

How do I know the bitrate of a file I already have?

Divide the file size in megabits by the duration in seconds. A 300 megabyte file is 2,400 megabits, and if it runs for 300 seconds that is 8 Mbps total, including audio. Most media players also expose this directly in a file properties or media information window.

Is it better to convert one long video or split it first?

If the whole thing is needed, convert it as one file. Splitting and rejoining introduces extra encode steps and can create visible seams at the joins. Split only when the pieces genuinely serve different purposes, and do the splitting from the master rather than from a converted copy.

The Short Version

Video conversion stops being mysterious once you separate the two questions it actually asks. The first is what box the file lives in, and changing that box costs nothing. The second is how the picture inside is compressed, and changing that always costs something, with the price set by the bitrate you allow.

Work from the best source you have. Rewrap instead of re-encoding whenever the codec inside is already acceptable. Trim before you compress. Match resolution to how the video will actually be watched rather than to what the camera recorded. Choose bitrate for the amount of motion in your footage. Do everything in a single pass, check a sample before committing, and keep the original safe.

Follow that and the difference between your converted file and the master will be something you have to hunt for rather than something anyone notices.