Source—
Kept—
Keyframe gap—
Output—
Trimming a video can cost nothing at all, or it can cost a full re-encode of every frame you keep — and which one you get is decided by a number no consumer tool shows you: how far your in-point is from the nearest keyframe. Only a keyframe can be decoded on its own, so a cut that copies the compressed frames has to begin on one. This tool measures that gap, lets you choose between a free copy that starts at the keyframe and a frame-exact re-encode that does not, and then checks the produced file packet by packet to confirm which it actually gave you.
Step by step
01Open the clip
MP4, MOV, WebM, or MKV. The tool reports the codec, the resolution, the measured frame rate, and how often keyframes appear.
02Place the handles
Drag them across the waveform of the clip's own audio, type exact times, or nudge with the arrow keys. Play loops the selection rather than the file.
03Read the keyframe gap
It says how much earlier a copied clip would begin. Zero means the copy is free; four seconds means a copy would include four seconds you did not ask for.
04Choose copy or frame-exact
Copy writes the compressed frames through untouched. Frame-exact decodes and re-encodes so the clip starts on the frame you chose. The ledger says which one the file you are about to download actually is.
A worked trim
The sample clip this tool opens with: ten seconds of 640×360 VP9 with Opus audio, 135 KB, keyframes roughly every two seconds. Asking for 0:03 to 0:07, both ways. Every figure is what the tool reports.
Given
The same request, both ways
copy starts 0:02 5.00 s 71 KB bit-identical frames
frame-exact starts 0:03 4.02 s 131 KB every frame re-encoded
for reference, the whole 10-second source is 135 KB
other copies:
0:00 → 0:05 5.00 s 70 KB
0:05 → 0:10 6.00 s 80 KB (begins at the 0:04 keyframe)Four seconds re-encoded came out at 131 KB — within a few kilobytes of the entire ten-second source — while five seconds copied came out at 71 KB. The re-encoder is not matching the source's bitrate; it is encoding to its own default quality, which for a clip that was originally encoded at a low bitrate means spending far more bits than the original ever did. So the frame-exact option costs you a second lossy pass *and*, frequently, a larger file. What you buy with it is one second of running time at the front. On this clip that is a poor trade; on a file with a keyframe every ten seconds it would be an excellent one. That is the whole reason the gap is on the screen — it is the only number that makes the choice answerable.
Before you trim
Most frames cannot be decoded on their own
A video stores complete images — keyframes — every few seconds, and everything between them as differences from the frame before. Start reading at a difference frame and there is nothing to apply it to, which is why a copied cut has to begin at a keyframe and why scrubbing in a player sometimes shows a smear before it settles.
A copied trim is genuinely free
The compressed packets are written into a new container untouched: no decoding, no encoding, no quality lost, and a running time bounded by how fast the file can be read rather than by how long the clip is. A two-hour recording trims in about the time it takes to read it.
A re-encode is often bigger, not just worse
The encoder is producing new frames at its own default quality, not reproducing the source's bitrate. On a clip that was originally encoded lightly, that means the trimmed file can approach or exceed the size of the whole original — which surprises people who reached for trimming as a way to make a file smaller.
Keyframe spacing varies enormously
A screen recorder may write one every second; a phone or a streaming download may go ten seconds between them. That single property decides whether a free trim lands where you wanted or four seconds early, and it is invisible in every file listing and every player.
Matching codecs does not prove a copy happened
A VP9 file re-encoded to VP9 still reports VP9. The only way to know is to compare the produced packets against the source's, which is what this tool does — and it is how the copy path here was found to be silently transcoding in an early version, because the trimmed file came out larger than the whole source.
Uploading a video to trim it is a poor trade
It is the slowest possible way to perform the cheapest possible edit: minutes of upload for an operation that is, done correctly, a file copy. It is also the operation people most often perform on footage that is not public yet.
The judgement call
The keyframe gap decides it, and the tool measures the gap for you.
The gap reads under a tenth of a second
Copy
Your in-point is effectively on a keyframe, so the copy is exact and free. There is nothing to be gained by re-encoding.
The gap is a second or two and the extra footage is harmless
Copy
A couple of seconds of lead-in costs nothing and keeps every frame bit-identical. Most trims are like this.
The clip has to start on an exact frame
Frame-exact
A cut on a specific word or action needs the re-encode. Expect a second lossy pass and, often, a larger file than the copy would have produced.
Trimming to make the file smaller
Copy
A copy keeps roughly the share of the bytes it keeps of the running time. A re-encode's size is set by the encoder and can end up larger than the original.
A two-hour recording
Copy
A copy is bounded by read speed; a re-encode has to process every frame, which on a long file is the difference between seconds and a very long wait.
The gap is ten seconds
Frame-exact, or move the handle
Ten seconds of unwanted lead-in is usually worse than a re-encode. Moving the in-point to the next keyframe instead is the third option, and it is free.
Reference
FAQ
Start the cut on a keyframe and copy the compressed frames into a new container. Only a keyframe can be decoded without the frames before it, so a copied trim can begin only where one already is. The Tinapps trim video tool measures how far your in-point is from the nearest keyframe, offers to begin the clip there, and confirms afterwards by comparing the output's packets against the source's.
Because the cut was copied rather than re-encoded, and a copy has to begin at a keyframe. If the last keyframe before your in-point was four seconds earlier, the clip begins four seconds early — that is the price of a free, lossless trim. Choosing the frame-exact mode removes it at the cost of re-encoding every frame you keep.
Not if the frames are copied — the trimmed clip is bit-identical to that span of the original. It does if the tool re-encodes, which is what happens when the cut has to land on an exact frame, and it is what most upload-based tools do to every trim regardless. The Tinapps trim video tool reports which of the two produced the file you are about to download.
Because it was re-encoded, and the encoder targeted its own default quality rather than the source's bitrate. On the sample in the Tinapps trim video tool, four seconds re-encoded comes to 131 KB against 135 KB for the whole ten-second source, while five seconds copied comes to 71 KB. If the goal was a smaller file, the copy is the mode you want.
A complete image, stored in full. Everything between keyframes is stored only as the difference from the frame before it, which is what makes video files small — and what makes them impossible to start reading at an arbitrary point. Keyframes typically appear every one to ten seconds depending on how the file was made.
Yes. The Tinapps trim video tool reads and rewrites the file with your browser's own video codecs through WebCodecs, so nothing is sent anywhere. That removes the upload wait entirely, which for a large clip is most of the time the job would otherwise take.
A few seconds for a copied trim, because a copy is bounded by how fast the file can be read rather than by its running time — a 2-hour recording trims in about the time it takes to read it. A frame-exact trim has to decode and re-encode every frame you keep, so its time scales with the length of the selection.
Yes — one switch drops the audio track entirely, which is a different operation from silencing it. Removing the track makes the file smaller and is what most platforms mean by a muted upload; some, however, require an audio track to be present, in which case a silent track rather than no track is what is needed.
The clip is read, cut, and written entirely in your browser through WebCodecs. Nothing is uploaded, and the trimmed file exists only as the download.
Keep going