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.
Initializing in your browser…
Combine CSV files with columns matched by name, so a reordered export still lands correctly, and every difference reported
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.
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.
Four clips of four different sizes, shapes and frame rates, joined in order.
Input
320x240 at 24fps, 640x480 at 30fps, 480x360 at 25fps, 640x360 at 30fps
Output
One 640x480 file at 30 fps, 3.8 s, with the 16:9 clip letterboxed rather than stretched
The same four clips through the old version came out at the FIRST clip's 320x240, at 48 fps which was none of the inputs, and 4.9 percent too long, with everything larger squashed into a quarter of its area and nothing said about any of it. The frame is now the largest clip, the rate the highest, each clip is scaled and padded rather than stretched, and the finished length is read back off the file and shown against the sum of the clips.
ffmpeg can join clips two ways and they are not interchangeable. The concat DEMUXER stitches the compressed packets together without decoding anything: it is instant, it is lossless, and it only works when every clip already has the same size, frame rate, codecs and sample rate. The concat approach used for everything else decodes each clip, fits it into one common frame and encodes it again: it costs time and a generation of quality, and it works on anything. The old version tried the first and treated whatever came back as a success. Measured on 2026-09-07, joining three clips deliberately made different from each other (320x240 at 24 fps, 640x480 at 30 fps, 480x360 at 25 fps, totalling 3.300 seconds) produced a 320x240 file at 48 fps lasting 3.461 seconds. The colours came out in the right order, so it looked fine. But the output took the FIRST clip's frame size, so the 640x480 clip was squashed into a quarter of its area; the frame rate was 48, which is none of the three inputs; and the length was out by 4.9 percent. Nothing said any of it. So the decision is now made in advance from the clips themselves, and printed. The page lists exactly why the clips cannot be stitched together when they cannot, names the common frame and frame rate it is going to use, and after the run reads the length back off the file it made and shows it against the sum of the clips.
Footage from a single device usually matches exactly, so the plan panel will say it can be joined untouched. That is instant and loses nothing.
Phone footage, a screen recording and a stock clip will not match. The plan says why, then fits them all into one frame without distorting any of them.
Clips with no audio get silence of their own length, so the join succeeds and the sound stays lined up with the pictures.
Cut the parts you want with the Video Trimmer first. Pieces cut from one source match each other, so the join here is lossless.
When the clips do not match, each one is fitted into the common frame on its own and the pieces are then joined losslessly, rather than everything being decoded at once in a single graph. That is a measurement rather than a preference: a three clip concat graph, which the native ffmpeg finishes instantly, reported no progress at all in the browser and had not finished after ten minutes, because one filter graph holding a decoder, a scaler and an encoder for every clip at once is more than the WebAssembly heap will take. Clip by clip it finishes in well under a second, holds one decoder and one encoder at a time, and gives a progress figure that moves per clip instead of one that never moves at all.
Fitting means scaling and padding, never stretching. A clip smaller than the common frame is scaled up to fit inside it and the rest is filled with black; a clip of a different shape is letterboxed rather than distorted. By default the common frame is the LARGEST of the clips, so nothing is enlarged beyond the biggest source you gave it, and you can choose the first clip instead. The frame rate is the highest of the clips, so no clip loses frames, and the sample rate is likewise the highest.
A clip with no audio track gets silence of its own length generated for it. Without that the pieces would not have matching streams and the join at the end would fail, which is a common way for a merge of mixed sources to die with nothing useful said.
One honest detail about the length. AAC codes audio 1024 samples at a time and pads both ends of every piece it encodes, so each clip can gain up to two frames, about 46 milliseconds at 44.1 kHz. Joining four clips can therefore come out around a tenth of a second longer than the clips add up to. The page states that bound in advance and prints both numbers afterwards rather than rounding the difference away.
Only if it has to. When every clip already has the same size, frame rate and codecs, the packets are copied straight through and nothing is decoded at all. When they differ, each clip is decoded and encoded again, which is one generation of loss. The panel tells you which of the two is going to happen before you press anything.
It is scaled to fit inside the common frame with its shape kept, and the leftover space is filled with black. Nothing is stretched and nothing is cropped. The previous version let the first clip decide the size and squashed everything else into it without saying so.
The largest one, by default, so nothing is enlarged past the biggest source you provided. You can switch it to the first clip if you want that instead. The frame rate is the highest of the clips, so no clip has frames dropped.
Because AAC codes audio in blocks of 1024 samples and pads both ends of each piece, so every clip can gain up to two blocks, roughly 46 milliseconds at 44.1 kHz. Four clips can therefore run about a tenth of a second over. The page states that bound before the run and prints the real length afterwards.
Yes. Silence of the right length is generated for them so that every piece has the same streams, which is what allows them to be joined at all. A merge of mixed silent and sounded clips fails outright without it.
Video is decoded and re-encoded on your own device. Large files never leave your machine.