Merge multiple MP4 files locally

Three same-camera MP4s — instant lossless join

Three 4-minute clips off the same phone, all H.264 1080p30 AAC. Because every stream matches, the concat demuxer copies them with -c copy and finishes in seconds. The output is bit-identical to the sources.

Inputs (added in this order):
  clip-A.mp4   H.264 1920x1080 30fps AAC   142 MB
  clip-B.mp4   H.264 1920x1080 30fps AAC   138 MB
  clip-C.mp4   H.264 1920x1080 30fps AAC   151 MB

Merger:
  -f concat -safe 0 -i list.txt -c copy out.mp4

Stage: (no re-encode warning shown)
Output: clip-A-merged.mp4  ~431 MB, lossless, done in ~4s

Wrong order — fix by remove + re-add

There is no drag handle. If clip C ended up second, you can't drag it down. Remove it and re-add it last with Add more. The list order IS the merge order.

List as added:    A, C, B   ← C is in the wrong slot
Desired order:    A, B, C

Fix:
  1. Click the trash icon on C  -> list is A, B
  2. Click 'Add more' and re-select C -> list is A, B, C
  3. Run

There is no reorder/drag UI — order = add order.

H.264 clip + H.265 clip — automatic re-encode

An iPhone HEVC (H.265) clip dropped in next to an H.264 export. The concat demuxer can't stitch different codecs, so pass 1 fails and the merger transparently re-encodes both through the concat filter to one H.264/AAC MP4.

Inputs:
  intro.mp4    H.264 1080p   AAC
  body.mov     H.265/HEVC    AAC   (iPhone)

Pass 1 (stream-copy) -> fails (codec mismatch)
Stage flips to: 'Codecs differ — re-encoding for clean concat'

Pass 2 (concat filter):
  -filter_complex '[0:v:0][0:a:0?][1:v:0][1:a:0?]concat=n=2:v=1:a=1[outv][outa]'
  -c:v libx264 -preset medium -crf 20 -pix_fmt yuv420p
  -c:a aac -b:a 192k -movflags +faststart out.mp4

Output: intro-merged.mp4  (re-encoded, always .mp4)

Mixed container output surprise

On the stream-copy path the output container follows the LAST file added — the merger overwrites its target extension with each input as it loops. If you add two MKVs then one MP4, a successful stream-copy writes .mp4. If it has to re-encode, the output is always .mp4 regardless.

Added: a.mkv, b.mkv, c.mp4   (all same codec/res/fps)
Stream-copy succeeds -> output extension = .mp4 (last file)

Added: a.mkv, b.mkv, c.mkv
Stream-copy succeeds -> output extension = .mkv

Any re-encode fallback -> always .mp4

Single file dropped — rejected

The merger is a multi-file tool. Dropping one clip throws immediately with a clear message. Use the trimmer or transcoder for single-file jobs.

Input: one_clip.mp4

Error: 'Pick at least two clips to merge.'

For a single file:
  - trim it -> /video-tools/lossless-trimmer
  - convert it -> /video-tools/video-transcoder

The merger throws Pick at least two clips to merge when fewer than two files are present. It is strictly a join tool. For single-clip jobs use lossless-trimmer or video-transcoder.

The Free tier caps batch jobs at one file, and the merger needs at least two — so Free can't run it. Pro raises the batch limit to 5 files, Pro + Media to 50, Developer to unlimited. This is a hard limit in the tier table, not a soft prompt.

Clips merge in the order they appear in the file list, which is the order you added them. There is no drag-to-reorder handle in the UI. To reorder, remove a clip (trash icon) and re-add it in the right position with Add more, then run.

When the stream-copy concat demuxer fails — usually because clips have different codecs, resolutions, or frame rates — the merger does NOT error out. It automatically re-encodes everything through the concat filter to H.264/AAC and shows the stage 'Codecs differ — re-encoding for clean concat'. You get a file either way.

On a successful stream-copy, the output container is taken from the LAST file you added (the loop overwrites the target extension on each input). The re-encode fallback always writes .mp4. If you need a specific container, run the merged file through video-transcoder afterward.

Each input is checked against your tier's per-file byte limit before processing (1 GB Free, 10 GB Pro, 100 GB Pro + Media / Developer). An over-limit file is rejected by name with its size and your tier's allowance. Shrink it with discord-compressor or trim it first.

Stream-copy preserves each clip's original timing and keyframe layout, so if clips have different GOP structures you can see a brief non-smooth transition at the seam. This is inherent to copying streams without re-encoding. A re-encode (which happens automatically for mismatched clips) produces a uniform timeline and removes it.

Without a chosen destination folder, the merged bytes are held in a blob in browser memory. Very large totals can exhaust the heap. Pro + Media streams output straight to disk via a destination handle, which is the supported path for multi-GB merges.

The re-encode concat filter maps audio optionally ([i:a:0?]), so a clip with no audio track won't crash the filter graph. On the stream-copy path, however, a missing audio stream in one clip can cause the demuxer to fail and trigger the re-encode fallback.

The dropzone only accepts .mp4, .mov, .mkv, .webm, .avi, .m4v, and .ts (or files with a video/* MIME type). Anything else is filtered out with a 'No video files in the drop' message before the merge runs.