Merge Files

About Merge Files Tool

File merging — also called concatenation — appends one file's bytes to the end of another in a defined order, producing a single output file. This is exactly what the Unix 'cat file1 file2 file3 > merged' command has done since 1971, and it remains the canonical way to reassemble split downloads (common for very large files transferred via slow or interrupted connections), combine numbered video/log chunks, recreate split CD images from .001/.002 parts, and join binary streams that were intentionally chunked for storage tier limits. This tool runs the concatenation entirely in your browser using the Blob and File APIs — files are read from disk, joined in memory, and offered as a single download without ever crossing the network. Works on any file type (binary or text), with custom ordering via up/down buttons, and includes built-in SHA-256 verification so you can confirm the reassembled file matches a vendor-published checksum. Try also our Batch Rename and Zip Files.

How do I reassemble files split by 7-Zip, WinRAR, or HJSplit?

Different split tools use different naming conventions and you must reassemble using the SAME tool: 7-Zip splits into .001/.002/.003 — open .001 in 7-Zip and it auto-finds the rest; WinRAR splits into part1.rar/part2.rar — open part1.rar; HJSplit creates .001/.002 but the format is just a raw byte split, so you can concatenate them with this tool. To check whether a multi-part archive is a raw byte-split (compatible with this tool) or a structured split (requires the original tool), inspect the first few bytes of .001: if they match a known archive header (PK for ZIP, Rar! for RAR, 7z for 7-Zip), the structured tool is required. Raw byte splits have no recognizable header in any individual part; they only become a valid archive once concatenated. Common video-camera 4 GB chunked clips (MP4 named C0001.MP4, C0002.MP4) are NOT compatible — they are independent valid MP4s, not raw splits.

Does merge order matter and how do I get it right?

Yes, order is critical: the merge concatenates bytes in the exact sequence shown in the list, so reordering produces a different output. For numbered splits (file.001, file.002, ...) order alphabetically — most file pickers sort that way by default, but always verify. For chunked downloads from a download manager, follow the numbering scheme used by the manager (often _001, _002 suffixes or .partN extensions). For text logs concatenated for analysis (e.g., access.log.1, access.log.2 from logrotate), reverse the apparent numbering: logrotate names .1 as the SECOND-MOST recent and .0 / no suffix as the LATEST, so to read chronologically you may need .5 first, then .4, then .3, etc. When in doubt, merge and check the file size matches the sum of inputs, then inspect the first and last few KB of the output to verify the expected boundaries.

What is the difference between merging files and creating a ZIP/TAR archive?

Merging produces a single byte stream — appending file B's bytes after file A's bytes — with no metadata about boundaries. The output is valid only if the inputs were originally split from one continuous file (where boundaries are arbitrary byte offsets, not file ends). A ZIP or TAR archive, by contrast, includes metadata about each contained file (name, size, timestamps, permissions) so the original files can be extracted back as separate entities. Merge when you want to reconstruct an original file from raw byte splits; use ZIP/TAR when you want to bundle separate files for storage or transmission. The fundamental rule: cat then split round-trips (cat a b > c; split c into a b reproduces originals); zip then unzip also round-trips with full metadata; but merging arbitrary unrelated files into one produces garbage in most file formats.

Why does the merged file fail to open even though the merge completed?

Four causes in order of frequency: (1) Wrong order — bytes are not where the file format expects them. Re-verify ordering. (2) Missing parts — if a download manager failed silently on part 5 of 10, your merged file is missing those bytes and the format becomes invalid. Check file count matches expected. (3) Corrupted parts — even one corrupted part (a few flipped bits during download) often invalidates checksums or signatures. Compare SHA-256 hashes if the source provides them. (4) Mismatched parts — accidentally including a file from a different split set produces an output that has the right total size but doesn't decode. Always merge files from the same source/timestamp set. To diagnose, the merged file should be the exact byte size of the original; if the size is wrong, the file count or ordering is off.

What's the largest file I can produce by merging?

The practical limit is browser memory because the entire output is assembled in a single Blob before download. Desktop browsers (Chrome, Firefox, Edge) reliably handle 1-2 GB outputs and can sometimes push to 4 GB on machines with 16+ GB of RAM. Safari is stricter. Mobile browsers cap closer to 500 MB. For larger merges (5+ GB video reassembly, database dumps), use the OS-native concatenation command: on Linux/macOS 'cat file1 file2 file3 > output' streams without loading into memory; on Windows 'copy /b file1+file2+file3 output' does the same. PowerShell users can use Get-Content -Raw piped to Set-Content. Cloud services (rclone, AWS CLI multipart, gsutil compose) handle TB-scale concatenation server-side. The browser approach is convenient but capped by RAM.

Can I add separators between merged text files?

This tool performs raw binary concatenation without inserting any separator. To insert separators between text files, three approaches: (1) After merging, open the result in a text editor and manually insert headers or blank lines at the file boundaries — easiest for a few files; (2) Use Unix command 'awk "FNR==1 && NR>1 {print \"\\n=== " FILENAME " ==="} {print}" file1.txt file2.txt > merged.txt' to add filename markers; (3) For automated workflows in Node.js: const merged = files.map(f => '=== ' + f.name + ' ===\n' + f.content).join('\n\n'); In Python: '\n\n'.join(f'=== {p.name} ===\n{p.read_text()}' for p in Path('.').glob('*.txt')). For CSV files specifically, separators are dangerous — they break the column structure. Use a dedicated CSV merge tool that strips duplicate headers and aligns columns instead.

How does this tool compare to Unix cat or Windows copy /b?

Functionally identical for the merge operation — all three produce the same byte-for-byte output. Differences: (1) Speed — OS-native commands stream from disk-to-disk without loading the full content into RAM, so they handle multi-GB merges that would crash a browser; (2) Convenience — this browser tool offers a visual drag-drop UI and ordering with up/down buttons, while CLI commands require manual ordering in the command line (which becomes painful with many files); (3) Privacy — both approaches stay local; nothing is uploaded; (4) Cross-platform — this tool works identically on Windows, Mac, Linux, Chromebook, iOS, Android without installing anything. For ad-hoc visual merges of 2-20 files under a few hundred MB total, the browser is faster end-to-end; for scripted production pipelines or huge files, cat/copy is the right choice.

How do I verify the merged file's checksum against the vendor's published SHA-256?

After the merge completes, this tool automatically computes the SHA-256 of the reassembled output and displays it in the Integrity Verification box — no separate hashing step or tool switch needed. To confirm the reconstruction is byte-perfect, paste the vendor-provided checksum (from the download page, a .sha256 sidecar file, or a release-signing manifest) into the 'Expected SHA-256' field. The tool normalizes both values (case-insensitive, ignoring spaces and colons) and shows a MATCH badge if they are identical or a MISMATCH badge if they differ. A MISMATCH means the reconstruction is wrong — almost always a part in the wrong order, a missing or truncated part, or a corrupted download — and the merged file should not be trusted. This is the exact verification step the failure-diagnosis FAQ refers to: a file that opens but is silently corrupt fails its checksum. If the source only publishes an MD5 or CRC32, those are weaker and not computed here; prefer SHA-256 when available, as it cannot be coincidentally matched by a corrupt reassembly. Everything runs locally via the browser's native crypto.subtle.digest, so the bytes never leave your device.