Cookies for analytics and advertising
We use cookies for analytics and advertising, both sent to Google. Refusing changes nothing you can see.Read the privacy page
Give a start time and an end time and get back only what is between them. The trim runs on your own machine — which matters more here than on most tools, because the clips people cut are usually the ones they would not hand to a website.
How it works
A video is not a row of independent pictures. Most frames describe only what changed since the last one, and they hang off a keyframe that carries a complete image. Cutting at an arbitrary second usually lands between keyframes, so the frames after the cut refer backwards to something that is no longer in the file.
The honest fix is to decode from the last keyframe and encode again, which is what happens here. It costs time on a long clip and one generation of quality, and it is the reason trimming takes seconds where rotating takes milliseconds. Tools that promise an instant lossless cut are either snapping your start time to the nearest keyframe without saying so, or leaving broken frames at the front.
People know a video is "about eight seconds in". Nobody knows they want frame 197, and the frame rate is whatever the camera felt like — 29.97 is still common enough to make frame arithmetic a trap.
Decimals work: 8.5 is halfway through the ninth second. If the end is left empty the clip runs to its own end, which is the usual case when you only want to remove a slow start.
The sound is cut to match, so the two stay in step. Subtitle tracks and alternate audio are not carried across — this is a trimmer rather than an editor, and quietly dropping a second language would be worse than saying so here.
The output is an MP4 whatever went in, because MP4 is the container that plays everywhere. If you need the original container back, the conversion pages will do that in a second afterwards.
Video is not stored one independent frame after another. Most frames describe only what changed since the last full picture, and those full pictures — keyframes — arrive every one to ten seconds depending on how the file was encoded. A cut that starts mid-run has nothing to build the first frame from.
So the cut has to come from somewhere, and here it comes from a re-encode: the decoder is run from the keyframe before your start time and the frames from your start time onwards are written out fresh. The cut lands on the second you asked for rather than drifting to the nearest keyframe, and the price is the generation of quality the section above describes.
Trimming changes when the video starts and stops. Cropping changes what is inside the picture — cutting the edges off the frame. They are unrelated operations that people routinely ask for by each other's name, and asking for the wrong one is the most common reason a result looks nothing like what was wanted.
The test is whether your problem has a clock in it. “The first thirty seconds are me fumbling with the camera” is a trim. “There is a doorway in the corner I want gone” is a crop, and a crop always redraws every frame because the frame itself is a different size afterwards.
The audio is cut at the same two points, with no fade at either end. If somebody is mid-word at your out point, the word is cut in half and it will sound abrupt rather than final.
Moving the cut into a pause is usually the whole fix and takes a few seconds of listening. A fade is a change to the samples themselves and therefore a re-encode of the audio — a different operation, and a reason to reach for an editor if the clip is going somewhere it will be judged.
No. The trim runs inside your browser and the file never leaves your device. That is worth more here than on most tools — screen recordings, medical scans and family video are exactly the things people would rather not hand to a website in exchange for a download link.
No, and no browser tool can make it so at an arbitrary second. Cutting between keyframes means the frames after the cut have nothing to refer back to, so the clip is decoded and encoded again. At default quality the difference is not visible, but it is a real generation of loss.
There is no limit written into the page, but there is one in your machine. The whole file is held in memory while it is worked on, so a phone with a two-hour 4K recording will run out before a laptop does. If it fails, that is what happened.
Not here. That is two cuts and a join, and joining two clips only works cleanly when they share a codec, a resolution and a frame rate — otherwise it needs a full re-encode of both halves. Doing it badly is worse than not offering it.
Yes. The audio is trimmed to the same start and end as the picture rather than being cut separately, which is the mistake that produces a clip where the voice runs ahead of the mouth by a growing margin.