Cut a clip out of a video, choosing whether the cut lands on the exact frame (re-encodes to MP4) or leaves the streams untouched (instant and lossless, but only at a keyframe). The result says which ran and reads the real length back off the file.
Initializing in your browser…
Convert a video between MP4, WebM, OGG, MOV, AVI and MKV, each naming the codecs it really writes and each producing a file that actually plays. One quality dial normalised into four different encoder scales.
Join clips end to end, saying in advance whether they can be stitched together untouched and, when they cannot, exactly which differences stop it. Clips of different sizes are letterboxed into one frame rather than squashed.
Speed a video up or slow it down, choosing what happens to the pitch (time stretch or resample) and to the frames (keep the rate or keep every frame). Both choices reach the export, and the finished length is read back off the file.
You ask for 0.700 to 1.300 seconds of a 30 fps clip, twice, once in each cut mode.
Input
counter.mp4 · start 0.700 · end 1.300 · keyframe every 15 frames
Output
Accurate: frames 21 to 38, 0.600 s. Copy: 0.95 s, because the keyframe is at 0.500
Both files are correct and they are not the same file, which is why the mode is now a choice rather than a guess. The accurate cut decodes and re-encodes so it starts on exactly the frame asked for; the copy leaves the compressed packets alone, which is instant and lossless and can only begin at a keyframe. After either one the tool reads the length back off the file it just made and prints it next to the length requested, so a 0.35 second overshoot is stated rather than discovered.
Modern video does not store every frame on its own. It stores keyframes that hold a complete picture and predicted frames that describe only what changed since a neighbour, and a typical H.264 clip has a keyframe every two to ten seconds. That structure is the whole reason "trim" means two different things, and this tool now makes you choose which one you want rather than deciding for you. **On the exact frame** decodes the range and encodes it again, so the clip starts on precisely the frame you picked no matter where the source keyframes fall. It costs one generation of quality and some time, and the output is MP4 with H.264 because that is what came out of the encoder. **Without re-encoding** copies the compressed packets straight through. It is instant and bit for bit lossless, and it can only start at a keyframe. How far that is from where you asked depends entirely on the source: measured on a test clip with a keyframe every half second, asking for 0.600 seconds from 0.700 gave a 0.95 second file, because the cut had to start at the keyframe before. The tool reads the length of the file it just made and prints it next to the length you asked for, so that gap is never a surprise. The previous version chose for you, and chose twice: it re-encoded, and then if that failed it silently fell back to a stream copy and said nothing at all. A cut that is seconds away from where you asked is not a detail to leave in a log.
Pull the best moment out of a longer recording. Use the accurate mode: a cut that starts a second early is worse than one generation of re-encoding.
Remove setup time and dead air. Screen recordings often have sparse keyframes, so the copy mode can be a long way out; the result panel will say by how much.
When the exact frame does not matter, the copy mode is instant and lossless whatever the file size, because nothing is decoded at all.
Type the timecodes rather than scrubbing. Meeting recordings usually come with a transcript that already has the times in it.
Everything runs in the browser through ffmpeg compiled to WebAssembly, so the file never leaves your device.
One small thing changed about how the accurate cut is made, and it is worth writing down because the code contradicted itself. The old comment here said that seeking before the input lands on a keyframe and drifts, so the seek was placed after the input; forty lines away in the same file the GIF converter said the opposite. Measured on a 30 fps fixture whose frames carry their own index, cutting 0.700 to 1.300 seconds: seeking after the input gave frames 21 to 38 with a duration of 0.6005 and a first frame timestamped 0.066 seconds; seeking before the input gave exactly the same frames 21 to 38 with a duration of 0.600 and a first frame at zero. ffmpeg has decoded past the keyframe to the requested time since version 2.1, so input seeking is not the blunt thing that comment described, and output seeking was leaving a two frame offset in the container that made some players open on a repeated frame. The seek is now before the input, which is also considerably faster because it does not decode everything ahead of the cut.
The container follows the choice rather than the upload. An accurate cut writes MP4, because H.264 and AAC belong in an MP4; the old behaviour of keeping the input extension meant that trimming a WebM produced a file named .webm containing H.264, which ffprobe could not read at all. A stream copy keeps the input container, because a stream copy does not change what is inside it.
Audio is copied through untouched when MP4 can hold it (AAC, MP3, AC-3 and ALAC), and re-encoded to AAC by name when it cannot (Opus and Vorbis). You can also drop it. And after every run the tool reads back the file it made and prints the length it really has, the way it was cut, the container, the size and the exact ffmpeg command line.
The editor is built for keyboard precision: Space toggles play and pause, I sets the start point at the playhead, O sets the end, the arrows seek (Ctrl or Cmd with an arrow moves one frame), M mutes and F is fullscreen. Start and end can also simply be typed, as seconds or as m:ss.cc.
Accurate unless you have a reason not to. It starts on exactly the frame you chose and costs one re-encode. Choose the copy mode when the file is large and the exact frame does not matter, or when the source must not be re-encoded at all; then read the result panel, which prints how far from your start point the keyframe actually was.
Because a copy cannot cut between keyframes. It has to begin at the keyframe at or before your start point, and it keeps everything up to your end point, so the clip comes out longer at the front. On a test clip with a keyframe every half second, a 0.600 second request from 0.700 came out as a 0.95 second file. The tool reads the length back off the file and shows you both numbers.
The copy mode does not touch the video at all, so no. The accurate mode re-encodes, which is one generation of loss; the default CRF of 20 is above the usual "near transparent" setting for that reason, and you can lower it further.
Because an accurate cut re-encodes to H.264 and AAC, and those belong in an MP4. The previous version kept the .webm extension around H.264, and the result was a file ffprobe could not read. If you need to keep the WebM container, use the copy mode, which does not change the streams.
Not from the start of a clip, no. That is a property of how video is compressed rather than of this tool: a predicted frame is defined in terms of frames before it, so a copy that began there would have nothing to predict from. The only way to start on an arbitrary frame is to decode it and write a new keyframe, which is what the accurate mode does.
Video is decoded and re-encoded on your own device. Large files never leave your machine.