“Without losing quality” is one of the most searched qualifiers in video editing, and almost every tool answers it with a marketing sentence rather than a mechanism. The honest answer is short: trimming a video costs you nothing at all if the file is never decoded, and costs you a generation of compression if it is. Which of those happens depends on one decision the tool makes on your behalf, and most tools do not tell you which one they took.
This guide explains the two modes, why you cannot always have the good one, and how to tell which you are getting.
The two ways to shorten a video
Stream copy (lossless)
A video file is a container — MP4, MOV, MKV, WebM — wrapping already-compressed streams. Cutting by stream copy means the compressed bytes are never touched. The tool finds the byte ranges you want to keep, copies them straight into a new container, rewrites the timestamps, and stops. Nothing is decoded and nothing is re-compressed, so the output is bit-for-bit the same picture as the input.
It is also close to instant, because copying bytes is far cheaper than decoding and re-encoding several thousand frames.
Re-encode (lossy)
Re-encoding decodes every frame back to raw pixels, applies whatever you asked for, and compresses it again. The second compression pass throws away detail the first pass already thinned out, which is why repeatedly re-encoding the same clip visibly degrades it — the “generation loss” people remember from tape.
A single re-encode at a sane quality setting is usually invisible on ordinary footage. It is not free, but it is not the catastrophe the phrase “losing quality” implies.
Why lossless trimming cannot always give you the cut you asked for
Here is the constraint that makes this interesting. In an inter-frame codec like H.264, most frames are not whole pictures. They are descriptions of how the picture changed since the last frame. Only keyframes (I-frames) are self-contained.
That means a stream copy can only start a clip at a keyframe. If it started anywhere else, the first frames of your new file would be instructions to modify a picture the decoder never received, and you would get the smeared, half-drawn mess you have probably seen at the start of a badly cut clip.
So a lossless trim always snaps your in-point back to the nearest keyframe at or before the time you asked for. How far away that is depends entirely on how the file was encoded:
| Source | Typical keyframe spacing | Practical effect on a lossless cut |
|---|---|---|
| Phone camera recording | Roughly 1–2 seconds | Cut lands within a second or so of where you asked |
| Streaming / live-oriented encodes | Commonly around 2 seconds | Similar; usually tolerable |
| Screen recordings of mostly static content | Often much further apart | The cut can land seconds early |
| Highly optimised archival encodes | Can be 10 seconds or more | Lossless trimming is effectively unusable for precise work |
None of those numbers are a rule — they are encoder settings, and every file is different. You can inspect your own file rather than guess; ffprobe will list the keyframe timestamps.
There is no way around this that keeps the copy lossless. To cut exactly where you want, the frames between the keyframe and your in-point have to be decoded so they can be rebuilt as a new self-contained frame — and once you have decoded them, you are re-encoding.
What this editor does, and why
alter.video re-encodes. Every operation — cutting a section out, speeding a section up, slowing one down — is built as an FFmpeg filter_complex graph, and a stream you are filtering cannot simultaneously be stream-copied.
That is a deliberate choice rather than an oversight, and it follows from what the tool is for. The main job here is removing a section from the middle of a recording — a fumbled sentence, a long silence, a doorbell. A section removal has two boundaries, and both of them have to be frame-accurate or the edit is visible. Snapping each of them to the nearest keyframe would routinely eat a second of good footage on one side and leave a second of the bad take on the other.
The encoder settings are libx264 at the ultrafast preset with CRF 28, plus AAC audio. Both numbers are chosen because the encoder is running inside a browser tab on your own CPU, not on a render farm: ultrafast trades compression efficiency for speed, and CRF 28 targets “looks the same at normal viewing distance” rather than “archival master”. On typical footage — phone video, screen recordings, talking heads — a single pass at those settings is not something you will notice. On very clean, very detailed source material, you might.
One consequence worth knowing: because the preset is fast rather than efficient, the output file is sometimes larger than the input even though the video is shorter. That is normal. ultrafast spends bits rather than time.
How to actually keep quality when you trim
A short list, in the order worth trying.
- Decide whether you need frame accuracy at all. If you are only lopping dead air off the very start and end of a clip and a second either way does not matter, a lossless keyframe-aligned trim is strictly better. Do that instead.
- Trim once, from the original. Every additional round trip is another generation. Make all your cuts in one pass rather than exporting, reopening, and cutting again. This editor stacks every edit into a single filter graph and encodes once for exactly this reason.
- Do not up-res or re-scale unnecessarily. Leaving the max-resolution control on “Original” avoids a resample. Scaling down to 720p is a legitimate size-saving move, but it is a separate, deliberate quality decision — not a free one.
- Judge the output, not the file size. A smaller file is not evidence of lost quality and a larger one is not evidence of preserved quality. Play the result at full size and look at the parts you care about.
- Keep the original. Whatever you do, the source file is the only thing that has not been through a generation. Do not overwrite it.
When to reach for FFmpeg directly
If your cut is at the ends of the clip, you do not need frame accuracy, and you want a genuinely lossless result, the command line is the right tool — and it is a two-line job. That case has its own walkthrough: trimming a video with FFmpeg without re-encoding, including how -ss behaves differently before and after -i, and why -c copy sometimes produces a file that starts with a frozen frame.
The short version
- Lossless trimming exists, is instant, and can only cut at keyframes.
- Frame-accurate trimming requires re-encoding, which costs one generation of compression.
- You cannot have both, and any tool claiming otherwise is quietly doing one of the two.
- One re-encode at a reasonable setting is not the disaster the phrase suggests; five of them is.
If you want the frame-accurate version in a browser with nothing uploaded, cut a section out of your video here. If you want the lossless version, the FFmpeg guide above has the exact command.