Cut a video without recompressing it: the cut that loses nothing

You have a four-minute video and you only need forty seconds of it. You open an editor, drop two markers, and hit export. The progress bar crawls for minutes, and the file you get back is heavier than it should be, softer, and has lost some of its quality without anyone telling you. You only notice when you compare the two frames side by side.

It does not have to work that way. Part of the problem is a belief: cutting a video means recompressing it. For most editors, that is true. They decode everything, then re-encode everything. It is not true for a stream-copy cut, which extracts the passage without touching the original compression.

Here is how that cut works, what it costs, and how to do it in two minutes.

What an editor does when you export

A video is a container, a bit like a box, that carries streams: a video stream, an audio stream, sometimes subtitles. Each stream is already compressed. When a conventional editor exports your passage, it decodes the frames, recalculates them, and encodes them again with the output settings. Every new compression adds errors the previous one did not have. Specialists call this generation loss.

LosslessCut, the tool I suggest here, describes the opposite approach on its official site: a standard editor re-encodes the whole file, while its lossless cut slices the data stream and copies it straight across. On the kept section, the output file contains the same data as the original. You re-encode nothing, so you lose no quality.

There is a side effect people miss. Without re-encoding, the job is a copy, not a calculation. LosslessCut says a cut takes seconds, so the time depends mostly on how fast your disk is, not on your processor.

Why the cut lands on a keyframe

A video does not store every frame the same way. Some frames are complete images, the keyframes. The others only describe what changed since the previous frame. To rebuild an intermediate frame, a player starts from the last keyframe and applies the differences one by one.

The consequence is direct. A cut without re-encoding cannot start anywhere, because the output file has to begin with a complete image. LosslessCut states it plainly: a lossless cut can only start at a keyframe, so the cut begins on the keyframe before your cut point, a fraction of a second earlier or several seconds, depending on the encoding.

If you cut at 1 min 42 s, the output may therefore start a few seconds earlier. That is not a bug in the tool. It is the price of the gain, and you read it in the file, not in a setting.

This also explains why a cut file sometimes opens a few seconds too early. It is not an export defect. It is the nearest legitimate starting point the tool could keep intact.

When to re-encode anyway

Three cases justify leaving the copy behind. The first: the video has to get lighter, because it is going over a limited connection or onto a nearly full drive. A copy shrinks nothing; you have to re-encode with a chosen bitrate or resolution, and accept the loss. The second: you need a frame-accurate cut for an excerpt that will be watched closely. The third: the output must match a fixed format (codec, resolution, profile) that a simple change of container cannot provide. In those cases the copy is the wrong tool. Better to know it before exporting than to compare two files afterwards.

The real question: copy or edit?

Before you pick a tool, ask one question: am I isolating a passage, or producing a new video?

If you are isolating a passage to find it later, show it to someone, or file it, a stream copy is enough. A few seconds of drift does not matter, and the quality stays that of the source. If you need to decide every frame (a precise excerpt, a cut on a given frame, a montage with transitions), you have to re-encode and accept the processing time.

This distinction prevents most bad choices. A file you want to keep intact is not a file you edit. A file you edit is not a file you archive. Mixing the two leads to re-encoding a video that only needed cutting.

What copying allows, and what it does not

With LosslessCut, you can cut and keep one or several segments, join them when their codecs match, change the container (an MKV to an MP4, for example) without re-encoding, or extract an audio track or a subtitle. The features page says that which operations are available depends on the file, its format and its codecs.

Changing what the stream contains is another matter. Lowering the resolution, switching codec, burning subtitles into the picture, applying an effect: each of these recalculates the frames. It is a different tool, a different setting, a different result. Do not chain them as if they were the same step.

One useful consequence: a file cut without re-encoding weighs roughly what the kept passage weighs. You do not save space by re-encoding what you just preserved. If you need a lighter file, that is a separate step with its own trade-offs.

The mistakes that come back

Exporting again in an editor, just to be safe. You re-encode what you had kept intact. The loss you wanted to avoid comes back, on top of the first one.

Joining segments from different sources. A join without re-encoding assumes identical codecs. Otherwise you have to re-encode, and the advantage disappears, usually without the tool warning you before export.

Expecting a frame-accurate cut. That is not what a stream copy is for. If you need frame precision, re-encode and accept the export time.

Assuming the start is exact. The start falls on a keyframe, and the end depends on how the source was encoded. Always check the first seconds of the output before you share it.

The two-minute method

Open the video in LosslessCut, find the start and end of the passage, and check that the export is a stream copy, with no re-encoding. Run the export. Then read the result: watch the first ten seconds and the last shot. If the passage opens on a frozen frame or with audio slightly out of sync, the start point fell on an earlier keyframe. Cut a little later, or accept the offset for this use.

If FFmpeg is already installed on your PC, the same cut fits on one line:

ffmpeg -ss 00:01:00 -i input.mp4 -t 40 -c copy output.mp4

It extracts forty seconds starting at the first minute, and -c copy tells FFmpeg to copy the streams instead of re-encoding them. The result follows the same keyframe rules as LosslessCut.

This is not a command to memorize. It is a gesture to try once on a test video, to see where the passage actually starts.

The same check works for a batch. If you cut several clips from one recording session, run the stream copy on one of them first and read where each start lands. Clips from the same device usually share the same encoding settings, so the offset you measure on the first clip tells you what to expect on the others. Adjust your cut points by that margin once, instead of re-checking every file by hand.

My rule

I cut without re-encoding by default, whenever the passage has to be found again or shared. I re-encode once, at the end, when the video is ready for its destination and the output format is set. One compression, at the last moment, is the simplest rule to keep.

That rule has a corollary for filing. A cut extract needs a name that says what it contains and when it was captured, then it should go into the project folder, not a pile of downloads. The five axes of organization give the logic for choosing where it goes, and the file name does the rest.

What this changes for you

Take a video you already have, and test a stream-copy cut on a thirty-second passage. Compare the start of the output with your cut point, then write down the gap. That measurement is the only thing you need to decide, case by case, whether a copy is enough.

To place this operation in a file routine (renaming, converting, archiving), the lesson Media & File Operations sets the frame: GUI or CLI, frequency, volume. If you want to save time across all your Windows settings before adding tools, the free guide to 10 Windows settings starts with the frictions that repeat every day.

Sources

LosslessCut features and behaviour checked on 5 November 2026.

See the source of this article

• LosslessCut, accessed 5 November 2026, LosslessCut: lossless video and audio cutting