How to stitch 4k clips together with no quality loss
- Step 1Confirm your 4K clips actually match — For a lossless stitch, every clip must share codec, resolution (e.g. all 3840×2160), frame rate, pixel format, and audio format. Same-camera/same-export clips usually do. If you're unsure, the merger will tell you by falling back to a re-encode.
- Step 2Open the merger on Pro + Media — Add your 4K clips at the video-merger tool. 4K files are large, so Pro + Media (100 GB per file, 50 files, streaming to disk) is the right tier. Pro works for smaller 4K sets within its 10 GB / 5-file limits.
- Step 3Add clips in sequence — Clips merge in the order added — there is no reorder handle. Drop or select them in playback order. To fix a mistake, remove the clip and re-add it in position with Add more.
- Step 4Pick a destination folder — On Pro + Media you'll be prompted for an output location. Choosing one routes the merge through the streaming write path so the multi-GB master never has to fit in memory.
- Step 5Run and watch the stage label — If the stitch stays on the copy path you'll see it finish in seconds with no re-encode warning. If the label flips to 'Codecs differ — re-encoding for clean concat', one of your clips didn't match and you're now getting a slow, lossy 4K re-encode — cancel and standardise the odd clip first.
- Step 6Verify the master is bit-identical — A successful stream-copy output is the concatenation of your source streams. Spot-check the first/last seconds and a join point; the picture should be visually identical to the sources because no pixels were re-encoded.
When a 4K stitch stays lossless
Stream-copy is only chosen when every property matches. Any mismatch forces the lossy re-encode fallback. This is the single most important table for 4K work.
| Property across clips | Must match for lossless? | What happens if it differs |
|---|---|---|
| Codec (e.g. all H.264 or all H.265) | Yes | Demuxer fails → re-encode to H.264 |
| Resolution (e.g. all 3840×2160) | Yes | Demuxer fails → re-encode |
| Frame rate (e.g. all 30 fps) | Yes | Demuxer fails → re-encode to a uniform timeline |
| Pixel format / bit depth | Yes | Demuxer fails → re-encode to yuv420p 8-bit |
| Audio codec / sample rate | Yes | Demuxer fails → re-encode audio to AAC 192k |
Lossless vs re-encode at 4K
Why confirming a match matters more at 4K than at 1080p: the re-encode penalty is far heavier.
| Aspect | Stream-copy (lossless) | Re-encode fallback at 4K |
|---|---|---|
| Command | -c copy (concat demuxer) | concat filter + libx264 -crf 20 |
| Quality | Bit-identical to sources | Re-encoded; 4K detail softened slightly |
| Speed | Seconds (byte copy) | Slow — encoding 8.3 MP frames in WASM |
| Output container | Last clip's extension | Always .mp4 |
| Memory pressure | Low (no decode buffers) | High — 4K decode + encode buffers |
Tier fit for 4K merges
4K files are big, so tier choice matters. Real per-file and batch limits.
| Tier | Per-file cap | Files | Streams to disk? |
|---|---|---|---|
| Pro | 10 GB | 5 | No — blob in memory |
| Pro + Media | 100 GB | 50 | Yes — recommended for 4K |
| Developer | 100 GB | Unlimited | Yes |
Cookbook
4K stitch scenarios. The recurring theme: lossless only happens when the clips match — confirm before you commit to a long job.
Four drone passes, same camera, same settings
Four 4K30 H.264 clips from one drone session, identical settings. Every property matches, so the concat demuxer copies them. A ~6 GB stitch finishes in seconds on Pro + Media streaming to disk.
Inputs (all 3840x2160 H.264 30fps AAC): pass1.mp4 1.4 GB pass2.mp4 1.6 GB pass3.mp4 1.5 GB pass4.mp4 1.7 GB -f concat -safe 0 -i list.txt -c copy out.mp4 Output: pass1-merged.mp4 ~6.2 GB, bit-identical, ~5s Streamed straight to chosen folder (Pro + Media).
One clip is secretly 25 fps
Three 4K30 clips and one 4K25 export sneaked in. The frame-rate mismatch makes the demuxer fail, and the merger re-encodes ALL four at 4K — slow and lossy. Better to detect and fix the outlier first.
Inputs: a.mp4 4K 30fps b.mp4 4K 30fps c.mp4 4K 25fps <-- mismatch d.mp4 4K 30fps Stage: 'Codecs differ — re-encoding for clean concat' -> 4K re-encode via libx264 -crf 20 (slow, lossy) Fix for lossless: re-export c at 30fps (or transcode it via /video-tools/video-transcoder) then re-merge.
Mixed H.264 + H.265 4K — lossless not possible
A 4K H.265 clip joined to 4K H.264 clips cannot stream-copy into one container as different codecs. The merger re-encodes to H.264. If you want lossless, transcode the odd clip to match the others' codec first.
Inputs: intro.mp4 4K H.264 main.mp4 4K H.265 <-- different codec -> re-encode (concat filter) to H.264 CRF 20, .mp4 Lossless route: transcode main.mp4 to H.264 (/video-tools/video-transcoder) so all clips share a codec, then merge -> stream-copy succeeds.
Container preservation on a clean 4K stitch
Your 4K clips are MKV (common for high-bitrate captures). A successful stream-copy keeps the container of the last clip added — here .mkv — so the master stays in your preferred container with no re-mux loss.
Added: cap1.mkv, cap2.mkv, cap3.mkv (all 4K, matching) Stream-copy succeeds. Output extension = .mkv (last file added) No re-encode, no container conversion — just concatenated packets in an MKV wrapper.
Memory-safe multi-GB master on Pro + Media
Stitching twelve 4K body-cam segments totalling ~40 GB. Choosing a destination folder routes the merge through the streaming writer, so the 40 GB output never has to live in the browser heap.
12 segments x ~3.3 GB = ~40 GB total (all matching 4K) Destination folder chosen up front. Stream-copy + streaming write: bytes are appended to the on-disk file as concat runs, not buffered in memory. Output: 40 GB .mp4 master, lossless, no OOM.
Edge cases and what actually happens
All 4K clips match
Lossless (stream-copy)When codec, resolution, frame rate, pixel format, and audio format all match, the concat demuxer copies the streams with -c copy. The output is bit-identical and the merge is near-instant regardless of how large the 4K files are, because no frames are decoded.
One clip differs from the rest
Re-encoded (lossy)A single mismatched property (e.g. 25 fps among 30 fps clips, or one H.265 clip) makes the demuxer fail and forces a full 4K re-encode through the concat filter to H.264 CRF 20. At 4K this is slow and softens detail. For lossless, standardise the outlier first with the transcoder, then re-merge.
4K re-encode runs out of WASM memory
Out of memoryIf the merger has to re-encode 4K and the source is large, decode + encode buffers can exhaust the WebAssembly heap, especially on mobile. Avoid this by keeping the clips matched (so it stream-copies) or by transcoding the odd clip down first. Mobile browsers are particularly memory-constrained for 4K work.
Merged 4K master exceeds memory on Pro (no streaming)
Out of memoryOn Pro, output is held as a blob in memory. A multi-GB 4K master may not fit. Pro + Media streams output to a folder you pick, which is the supported path for large 4K merges — choose that tier for big jobs.
A 4K clip exceeds the per-file size cap
RejectedEach clip is checked against the per-file byte limit (10 GB on Pro, 100 GB on Pro + Media / Developer). A single 4K clip over the cap is rejected by name. Pro + Media's 100 GB ceiling covers essentially any practical 4K source.
Stutter at a seam after a lossless stitch
ExpectedStream-copy preserves each clip's keyframe layout. If two same-source 4K clips happen to have different GOP boundaries (e.g. different open/closed GOP settings), a brief hitch can appear at the join. This is inherent to copying without re-encoding; it disappears only if the clips are re-encoded to a single timeline.
HDR / 10-bit 4K clips
Handled (on the copy path)On the lossless stream-copy path, 10-bit / HDR streams are copied untouched, preserving the pixel format and metadata. But if a mismatch forces the re-encode fallback, libx264 outputs yuv420p 8-bit — which loses HDR. For HDR work, keep all clips matched so it stream-copies.
Only one clip provided
RejectedThe merger requires at least two files (Pick at least two clips to merge). To trim or re-wrap a single 4K clip losslessly, use lossless-trimmer instead.
Wrong stitch order
By designClips concatenate in add order; there is no drag-to-reorder. For a long 4K reel, double-check the list order before running — re-ordering after a slow merge means doing it again. Remove and re-add to fix order.
Audio sample-rate mismatch between 4K clips
Re-encodedEven if video matches, differing audio sample rates (48 kHz vs 44.1 kHz) cause the demuxer to fail and trigger the re-encode fallback, which normalises audio to AAC 192k. To keep the stitch lossless, ensure all clips use the same audio format.
Frequently asked questions
Will stitching my 4K clips reduce their quality?
Not if the clips match. When codec, resolution, frame rate, pixel format, and audio format are all identical, the merger uses -c copy to copy the encoded 4K streams byte-for-byte — the output is bit-identical to your sources. Re-encoding (and the small quality cost) only kicks in if one clip differs and can't be stream-copied.
How can a 4K merge be lossless and still fast?
Because stream-copy never decodes or re-encodes the picture — it copies the already-encoded packets. The work is moving bytes, which is the same speed whether the frames are 1080p or 4K. That's why a multi-GB 4K stitch finishes in seconds.
How do I know my clips will stream-copy instead of re-encode?
They will if every property matches: same codec, resolution, frame rate, pixel format, and audio codec/sample rate. Same-camera or same-export clips almost always do. The clearest signal at run time is the stage label — if it flips to 'Codecs differ — re-encoding for clean concat', one clip didn't match.
What if one of my 4K clips is a different frame rate or codec?
The lossless path fails and the merger re-encodes all clips to H.264 CRF 20 — at 4K that's slow and slightly lossy. For a true lossless stitch, fix the outlier first: transcode it to match the others with the video-transcoder, then re-merge so the stream-copy path succeeds.
Can I merge 4K HDR / 10-bit clips without losing HDR?
Yes, on the stream-copy path — HDR/10-bit streams are copied untouched. But if a mismatch forces a re-encode, libx264 outputs 8-bit yuv420p and HDR is lost. So for HDR, make sure all clips match so the merger copies rather than re-encodes.
Which tier should I use for 4K merges?
Pro + Media. It allows 100 GB per file and 50 files, and crucially it streams the merged output to a folder you pick instead of holding gigabytes in browser memory. Pro (10 GB / 5 files, blob output) is fine for smaller 4K sets.
Is my 4K footage uploaded to a server?
No. Everything runs in your browser via FFmpeg.wasm. Your 4K clips are read locally and the merged master streams to your disk on Pro + Media — nothing is transmitted, which is important for unreleased or confidential 4K material.
Why did my 'matching' 4K clips still re-encode?
Some mismatch is hiding. Common culprits at 4K: one clip at 29.97 fps vs 30 fps, a different audio sample rate, a variable vs constant frame rate, or a 10-bit clip among 8-bit ones. Any of these makes the concat demuxer fail and triggers the fallback.
Can I reorder 4K clips after adding them?
Not by dragging — there's no reorder handle. Clips merge in the order added. Because a re-ordered 4K merge means re-running the job, double-check the list order first. To change order, remove a clip and re-add it in position.
What container will my 4K master use?
On a lossless stream-copy, the output uses the container of the last clip you added (e.g. .mkv or .mp4). If the merger has to re-encode, it always writes .mp4. To force a specific container, run the master through the video-transcoder afterward.
Is there a duration limit for the stitched 4K master?
No minutes cap — limits are by file size and count, not duration. You can stitch an hour of 4K as long as each input is within the per-file size cap and the total fits your batch count. Pro + Media's streaming write is what makes long, large masters practical.
What if I just want to trim, not stitch, a 4K clip?
Use lossless-trimmer. It stream-copies a single clip at keyframe boundaries with -c copy, so it's the lossless single-file counterpart to this merger.
Privacy first
Every JAD Video tool runs entirely in your browser via WebCodecs and FFmpeg (WebAssembly). Your video files never leave your device — verified by zero outbound network requests during processing.