Video Merger

Add the clips, leave Method on Auto, and check that the comparison says they match. When it does, the clips are joined by copying their compressed packets into one track — nothing is decoded, so there is no quality to lose and no setting that could change that. This is the normal outcome for clips from one camera or recorder, and it takes seconds rather than minutes. Quality is only ever lost when the comparison finds a genuine difference and the clips have to be re-encoded to a common set of settings.

Drop the whole folder in at once, press By name, and merge. Action cameras and dashcams split a recording into numbered files because of a filesystem limit rather than because anything about the footage changed, so every part shares a codec, a frame size, and an audio layout. That is exactly the case a stream copy is for. Natural sorting puts GX010042 before GX020042 and clip2 before clip10, so the running order is usually correct after one click.

No. The engine is FFmpeg compiled to WebAssembly and it runs inside your browser tab. Each clip is read from disk into the tab's memory and the joined file is written back out as a download. Nothing about any of them crosses the network, which you can confirm by watching the network panel while a merge runs.

Yes, but not for free. One video track can declare only one frame size, so mixed resolutions mean every clip is decoded, scaled to a common frame, and encoded again. You choose the frame — the largest clip's, the first clip's, or a preset — and how clips of a different shape are fitted into it: padded with bars, cropped to fill, or stretched. The comparison tells you which clip differs before you commit to the time.

That is what a stream copy looks like when the clips were not as compatible as the tool doing the joining assumed — the first clip's description is written into the track, later packets do not fit it, and the player stops or freezes. It is the classic failure of joining files with a command copied off the internet. This tool compares the clips first, and reads the finished file back to check it is as long as the clips that went into it, so a short join is reported instead of handed over. If you see that warning, switch Method to Re-encode.

Yes. The list plays top to bottom, and you can drag any row to a new position, nudge it with the arrow buttons, or sort the whole list by filename or by the date each file was written. Reverse flips the lot. Each row carries a thumbnail so you can see what is where rather than working it out from the names, and the order can be changed right up until you press Merge.

Silence is generated for exactly that clip's length and joined in its place. This matters more than it sounds: without it, the clip contributes no audio at all and the sound of every clip after it starts early, so a title card at the front of a video puts the whole soundtrack out of sync. Mixing clips with and without audio also means the join has to be re-encoded, because the presence of an audio track is part of what a single track declares once.

Usually yes, and often without re-encoding. MOV and MP4 are different wrappers around the same H.264 and AAC streams, so what matters is not the extension but whether the streams inside agree — the same frame size, pixel format, and audio parameters. The comparison checks that directly and ignores the container. Pick MP4 or MOV as the output and the clips are copied into it if they match.

Up to twenty clips in one join. The real limit is memory rather than count: every clip is held in the tab alongside the finished file, and WebAssembly is 32-bit, so a combined size beyond roughly a quarter of a gigabyte becomes unreliable. A copy is quick almost regardless of total length, because nothing is decoded. A re-encode scales with duration and resolution and runs on a single thread, so a long, high-resolution set takes real time.

No. Clips are joined end to end with a hard cut at each seam. Adding a crossfade would mean decoding and re-encoding every clip even when they match perfectly, which would throw away the thing that makes this tool worth using. If you need transitions, a video editor is the right tool; if you want the clips joined, this does that without cost.

Because they were different jobs. A set of matching clips is copied, which is mostly a matter of writing bytes. One clip that differs — a different resolution, a sideways phone recording, a clip with no audio among clips that have it — means the whole set has to be decoded, normalised, and encoded as one video. The comparison panel names the property and the clip responsible, so you can often fix the input instead of paying for the re-encode.

Leave it as it is, in most cases: the output defaults to the container your first clip is already in, which is the one guaranteed to accept these streams without re-encoding. Choose MP4 explicitly when the result has to be shared, uploaded, or played on anything; MKV when a copy is being refused, because it accepts almost any stream; MOV when the destination is Final Cut or QuickTime; and WebM only when you specifically need an open format on a web page, since it always costs a full re-encode.