Trim a video without re-encoding a single frame

Type where the clip starts and ends. The frames you keep are copied across byte for byte, so there is no quality loss and a very large file takes seconds. Nothing is uploaded.

m:ssMoved back to the nearest keyframe. Empty means the start.
m:ssEmpty means the end of the video.

Drop your video here

or click to browse. Nothing is re-encoded, so a 2 GB file takes seconds and the picture is untouched. Stays on your computer.

Set a start or an end first

With both boxes empty this would hand back the whole video unchanged. Type where the clip should begin, where it should end, or both.

Identical quality

Not “almost”. The compressed frames that come out are the ones that went in.

Seconds, not minutes

Nothing is decoded, so the work is reading and writing bytes. Size barely matters.

The sound comes too

Copied across the same way, in sync, untouched.

Nothing is uploaded

No server sees the file. There is no queue and no size tier.

Copying frames instead of remaking them

Most browser trimmers decode your video into pictures, throw away the ones outside the range, and encode what is left back into a new file. That works, and it costs you two things: minutes of waiting proportional to how long the clip is, and a generation of quality, because the frames are compressed a second time.

Neither cost buys anything here. A trim does not change any picture — it changes which pictures are in the file. So this tool opens the container, copies the compressed frames in your range into a new one, shifts their timestamps back to zero, and writes it out. The bytes describing each frame are never even looked at.

The catch, stated plainly

Frames are not independent. Every second or two there is a keyframe holding a complete picture, and everything between one keyframe and the next is stored as a difference from what came before. Handing a player a frame without the keyframe it depends on gives you a grey smear.

So the start of the cut moves back to the nearest keyframe at or before the time you asked for. On an ordinary phone video that is a fraction of a second. On a long screen recording, which can go ten seconds between keyframes, it can be noticeable. The result line says how far it moved every time, rather than quietly handing you something that starts in the wrong place.

The end is not affected in the same way: frames after your end point are simply not copied.

What this tool cannot do

It cannot cut at an exact frame. See above. That needs a re-encode, which is the thing being avoided.

It cannot cut a piece out of the middle. One continuous stretch, kept; everything else, dropped.

It cannot make the file smaller than its share. Keeping a third of a video gives you roughly a third of the bytes. To go below that you want the video compressor, which does re-encode.

It cannot open every container. MP4, MOV, MKV, WebM and MPEG-TS. An AVI or a WMV is refused outright — no browser opens one — and you are told so rather than left waiting. The video compressor takes those, because it carries an engine that can read them; that engine is also what makes it a re-encode.

Answers

Why did my cut start a second early?

Because a video is not a stack of independent pictures. Every so often there is a keyframe — a complete image — and the frames after it are stored only as the differences from what came before, so they mean nothing on their own. A cut that does not re-encode has to begin at one of those keyframes, so the start is moved back to the nearest one at or before the time you typed. The result tells you exactly how far it moved.

How do I cut at exactly the frame I want?

You would have to re-encode the beginning of the clip, and then it is no longer instant and no longer lossless. This tool does not do that, on purpose. If the extra second matters more than the quality, a full editor is the right thing to use.

Is the quality worse afterwards?

No, and not "barely" — it is identical. Every compressed frame that comes out is the same sequence of bytes that went in. Only the container around them is rewritten, which is why the whole thing takes seconds even on a very large file.

Why is my WebM now an MP4, or my MKV an MP4?

The output container has to be one that can carry the codec your video already uses, and MP4 is preferred because it plays in more places. H.264 and HEVC go into MP4 — an MKV holding H.264 therefore comes back as an MP4. VP8, VP9 and Opus go into WebM. Nothing about the picture changes either way.

What happened to the sound?

It is copied across untouched, in the same way as the picture. The one exception is a soundtrack in a codec the output container cannot hold, such as AC-3 — re-encoding it would break the promise this tool is built on, so it is left out and the result says so.

Can I cut a piece out of the middle and join the ends?

No. This keeps one continuous stretch and discards the rest. Removing a section from the middle means joining two pieces, and joining them without re-encoding only works when they line up exactly, which they generally do not.

Other tools