Video Trimming and Compression, Explained
After reading this you will know when a video can be cut without re-encoding, why keyframes limit where a lossless cut can land, and how a quality setting turns into a file that is half or a tenth of the original size.
What the tool does and one example
A video file is a container (like MP4 or WebM) holding one or more streams: usually one video track and one audio track. Trimming keeps a time range and discards the rest. Compression re-encodes the kept frames at a lower bitrate to shrink the file. Muting drops the audio stream entirely.
Here is the hook. Suppose you have a 3 minute 1080p screen recording at 40 megabits per second. That is roughly 40 Mbit/s × 180 s ÷ 8 = 900 MB. You only need the middle 30 seconds, and it does not need to be full quality. Trim to that 30 second window and re-encode at 4 Mbit/s and you get about 4 × 30 ÷ 8 = 15 MB. That is 1/60 of the original, and it happens in your browser with no upload.
Lossless trim versus re-encode
There are two ways to cut a video, and they behave very differently.
- Lossless trim (stream copy)
- The encoded video packets are copied straight into a new file. No pixel is decoded or re-encoded, so quality is identical and the operation is fast, often faster than the video plays.
- Re-encode
- Every frame in the range is decoded to pixels and encoded again at your chosen quality. This is frame-exact and lets you compress, but it costs CPU time and always loses a little quality.
The catch with lossless trim is keyframes. A modern codec does not store every frame in full. It stores occasional complete frames (keyframes, also called I-frames) and, in between, frames that describe only the change from previous frames (P-frames and B-frames). You cannot start decoding in the middle of that chain, so a stream copy must begin at a keyframe.
Keyframe spacing is set by whoever encoded the file. Two seconds is common, so a keyframe every 48 to 60 frames at 24 to 30 fps. Some recordings use ten seconds or more, which makes lossless cuts land far from where you asked.
Why the cut point can drift
Ask a lossless trim to start at 12.0 seconds when the nearest earlier keyframe is at 10.0 seconds, and the file starts at 10.0 seconds. You get two extra seconds. Ask to start at a point where the nearest keyframe is 1.9 seconds away and you get 1.9 extra seconds.
The drift is bounded by the keyframe interval. If keyframes are spaced G seconds apart, the worst-case error is just under G seconds:
Here t_{\text{req}} is the start you requested, t_k are the keyframe timestamps, and t_{\text{actual}} is the last keyframe at or before your request. A re-encode has no such constraint because it rebuilds the frames, so it can start on any single frame, giving an error under one frame time (about 0.033 s at 30 fps).
How a quality setting becomes a bitrate
Compression is a trade between file size and visible detail. Two knobs control it. The first is bitrate, measured in bits per second: multiply by duration and divide by 8 to get bytes.
The second knob is a quality target such as the H.264 CRF (Constant Rate Factor). Instead of fixing the bitrate, the encoder aims for a constant perceived quality and spends whatever bitrate that needs. CRF runs from 0 (lossless) to 51 (worst). A useful rule of thumb: every increase of about 6 in CRF roughly halves the bitrate.
Here c is the CRF, c_0 is a reference CRF, and b_0 is the bitrate observed at that reference. The value b_0 depends heavily on content: a still slideshow compresses far smaller than confetti falling on grass. The formula predicts how the same clip scales when you change CRF, not the absolute size across different clips.
A worked example with the defaults
Run the demo, which uses the field defaults, and follow the arithmetic.
Trim to 30 seconds and compress
- Start with a 1080p clip encoded at 40 Mbit/s video plus 128 kbit/s audio, running 180 seconds.
- Original size: video is
40e6 × 180 ÷ 8 = 900 MB; audio is128e3 × 180 ÷ 8 ≈ 2.88 MB. Total about903 MB. - Trim to the range 60 s to 90 s, a 30 second window. If keyframes sit 2 s apart and you request 60 s, a lossless start could land as early as the keyframe at 58 s.
- Because you also compress, the tool re-encodes, so the cut is frame-exact and starts at 60.0 s.
- Re-encode at CRF 26. Say the encoder produces about 4 Mbit/s for this content. Video size:
4e6 × 30 ÷ 8 = 15 MB. - Keep audio at 128 kbit/s:
128e3 × 30 ÷ 8 = 0.48 MB. Output about15.5 MB, roughly 1/58 of the original.
Mute the audio and you save that 0.48 MB. On a 30 second clip that is a rounding error. On a 60 minute lecture at 128 kbit/s it is about 57 MB, which is worth removing when the audio is not needed.
Reading the result
Check three things after a run. First, the duration: it should match your window within a frame for a re-encode, or within one keyframe interval for a lossless trim. Second, the file size against your bitrate estimate; if it is far off, your CRF assumption about b_0 was wrong for this content. Third, playback quality at the parts with most motion, since that is where a too-high CRF shows blocking first.
| CRF | Look | Relative size vs CRF 23 |
|---|---|---|
| 18 | visually lossless | 2.52 |
| 23 | default, good | 1.00 |
| 28 | noticeable on motion | 0.561 |
| 32 | clearly soft | 0.354 |
Common mistakes
Expecting a lossless trim to be frame-exact. It cannot be. If you need the cut on an exact frame, use the re-encode path and accept the extra time. If a couple of seconds of drift is fine, keep the copy and save the wait.
Two more traps. Chasing tiny CRF values like 16 for footage that will be watched on a phone wastes bandwidth: the phone screen cannot resolve the extra detail, yet the file may triple. And re-encoding an already compressed file repeatedly stacks loss; each pass throws away detail the previous pass kept, so archive the original and re-cut from it rather than from a compressed copy.
Finally, AV1 is not supported by this engine. If your source is AV1, transcode it to H.264 elsewhere first, or the tool will refuse it.
Related tools
If you only need the sound, cut it directly with the Audio Trimmer, which also adds fades. When a clip's audio is too quiet or too loud after trimming, run it through the Volume Normalizer to hit a target peak or loudness before you compress.
Frequently asked questions
Why did my trimmed video start earlier than I set?
A lossless trim must begin on a keyframe, so it snaps back to the nearest keyframe at or before your start. If keyframes are 2 seconds apart, you can get up to nearly 2 extra seconds. Use re-encode mode for a frame-exact start.
What CRF should I pick?
Start at 23 for general use. Drop to 20 if you see blocking on motion. Rise to 28 or 30 when file size matters more than fine detail. Every 6 steps roughly halves or doubles the size.
Does muting the audio make the file smaller?
Yes, by the whole audio stream. At 128 kbit/s that is about 0.96 MB per minute, so 57 MB per hour. On short clips the saving is negligible.
Are my files uploaded anywhere?
No. The encoder runs as WebAssembly in your browser, so the video never leaves your machine.
Why is the first run slow?
The encoder is about 25 MB and downloads from a CDN the first time, then stays cached. Later runs skip the download.
Related tools
Audio Trimmer
Cut a section out of an audio file, with fades.
Volume Normalizer
Normalize audio to a target peak or loudness.
Audio Format Converter
Convert between WAV, MP3, OGG, FLAC, M4A and more.
Chord Identifier
Name any chord from notes you pick or type.
Euclidean Rhythm Generator
Generate world-music rhythms from two numbers.
Extract Audio from Video
Rip the audio track of a video to MP3, WAV or FLAC.