Trim a video

Choose a start and an end, and this tool writes a new file containing only the frames between them, copied across in their existing compressed form. Nothing is decoded and nothing is re-encoded, so a 6-second cut out of a 720p clip finishes in about 29 milliseconds and the picture is bit-for-bit what it was. The trade-off is specific and we report it rather than hide it: the start moves to the nearest keyframe.

Why the cut cannot start exactly where you asked

Compressed video does not store every frame as a picture. It stores occasional complete frames — keyframes, also called I-frames — and then, for everything in between, only the difference from frames nearby. A frame in the middle of that run is meaningless on its own; it is a set of instructions for modifying a picture you would have to already have.

So a cut that keeps the bytes has to begin on a keyframe. If you ask for 4.0 seconds and the nearest keyframe at or before that is at 3.0, the result starts at 3.0. Starting at 4.0 instead would give you a first second of grey blocks and smeared movement, which is what happens when a tool cuts wherever it is told without saying anything.

This page finds the keyframe before your chosen point, shows you where the cut will actually land before you commit, and reports it again on the result. How far off it can be depends entirely on the recording: at one keyframe per second the error is at most a second, but phones commonly record with two to four seconds between keyframes, and there the difference is obvious. The file information panel shows the measured keyframe spacing for your specific file, so you know what to expect instead of guessing.

What the alternative costs

Frame-accurate trimming is possible, but only by re-encoding: you decode from the keyframe up to your chosen frame, compress that opening section again, and join it to the untouched remainder. That gives an exact start and costs a lot for it. In our measurements the same trim took about 29 milliseconds copying packets and about 912 milliseconds going through the library's high-level path that re-encodes — roughly thirty times slower on a six-second clip, and it scales with length, so a long video goes from instant to minutes.

It also costs quality. Re-encoding the opening section means it no longer matches the rest of the video, and the loss is permanent. For most reasons people trim — cutting dead air off the front, dropping the part where you fumble for the stop button, getting a clip under a length limit — a start that is up to a keyframe early is not a problem at all.

We have not built the frame-accurate version, and we would rather say so than do it quietly. A tool that silently re-encodes to hit your exact number is making a large decision on your behalf and charging you for it in quality. If you need exact frames, an editor is the right instrument.

What happens at the end, and to the audio

The end point does not have the same constraint, because a video can stop on any frame. Everything up to your chosen time is included, so the result ends on the last complete frame before it. Leave the end field alone and you get everything from the start point to the end of the file, which is what you want when you are only cutting off an opening.

The audio is cut alongside the video from the same point. Audio frames are short — around twenty milliseconds each — so the audio start is much closer to your requested time than the video start can be. Both tracks are then shifted by the same amount when the file needs it, which keeps the relationship between picture and sound exactly as it was in the source. Getting that wrong is the classic way trimmed clips end up with the sound slightly out, and it is subtle enough to survive a casual check.

Rotation metadata is preserved, so a portrait recording stays portrait. If your file has more than one audio track, the first is kept and the page tells you what it left behind.

No upload, no limit, and how to check

The file is read, cut and written inside this browser tab. There is nothing to upload, so there is no size cap to work around, no queue, no watermark and no account. That is not generosity — it is that processing costs us nothing when it happens on your device, so there is nothing to ration.

To check, open your developer tools, switch to the Network tab and trim something. Your video is in none of the requests. The Content-Security-Policy header this site sends restricts connections to our own origin, so the browser itself would block an attempt to send it. And after the first visit the page works with no connection at all.

The real constraint is memory: the output is assembled in the tab, so allow for its size plus about a hundred megabytes of working space. Roughly 500 MB of input is comfortable on a desktop and half that on a phone. Trimming helps here, because the output is only as large as the part you keep. The page warns you when a file is above the guideline instead of letting the tab fail without explanation.