Two txt files dragged in, 2 lines each, and the merge returns 3 lines. The middle one reads bravocharlie: the last line of the first file and the first line of the second were welded together with no warning. A line count mismatch investigation starts here.
Merging is one join in this tool. The whole front end is 234 lines with zero external dependencies, and the default entry in the separator dropdown, "none", is mapped in the code to an empty string of length 0. So alpha + bravo (11 bytes) joined with charlie + delta (13 bytes) gives 24 characters over 3 lines. split yields alpha, bravocharlie, delta, and the swallowed line reports no error in any panel.
The root cause is that neither file ends with a newline: the byte missing at the end of a line is exactly where the next file starts, and filling it with an empty string only creates a weld.
The file name marker checkbox does not prevent welding
The most believable rescue looks like turning file name markers on, but the marker is added before the content. Same two files, default separator, and the result becomes 76 characters over 5 lines with the middle line reading bravo===== tm_b_nonl.txt =====: the weld did not go away, the marker string merely covered part of it. Move the separator to the blank line setting and the result is finally 78 characters over 7 lines, clean line by line: the blank line pads at least one newline between every pair of files, so marker and body each take a line of their own.
Each file's own BOM is silently dropped
The second invisible rewrite happens during reading. The call that turns a file into text carries no encoding argument, so the browser strips the U+FEFF at the head of every file as a BOM, spec behaviour rather than a bug, and it is gone from the result. Merge two 7 byte files that each carry a BOM and the output has U+FEFF 0 times, 9 characters and 9 bytes. The same pair of files, the same merge code, read a different way with no BOM stripping gives U+FEFF 2 times and 15 bytes.
The tool does not keep the BOM of your original files. A downstream script that recognises UTF-8 by BOM will judge the product unsigned without saying so.
textarea eats CR and the statistics never hear about it
Put a CRLF file next to an LF file: crlf (8 bytes) plus lf (6 bytes), concatenated as they are, is 15 characters holding 2 \r\n. The moment that string enters the result textarea the browser normalises it to LF, leaving a value of 13 characters and 0 \r\n. The total characters line on the panel was computed before normalisation and still reads 15. The downloaded file is 2 bytes smaller than the stat.
Copying and downloading both take the already normalised value, one source. new Blob([v]) pushes a single element with no U+FEFF in front of it, and the measured gap of copy 13 characters against download 26 bytes comes entirely from the multi byte UTF-8 characters themselves. A BOM changes no bytes here.
The order is neither natural order nor selection order
Searching the text merge template for anything sort related is a dead end, there is no sort and no localeCompare, because it never sorts. Select 10.txt, 2.txt and 1.txt in one go and the output keeps the order ten, two, one.
That still does not make the order the order you selected. Entries push into the list as each one finishes reading, so whoever reads first takes a slot first. Drop a 1,048,576 byte file together with an 11 byte one and the small file lands ahead of the large one. Among four same-batch drops, one crossed over. If you need a fixed sequence, do not ask it of the drop step: run the text through text sort and dedupe to straighten the lines, or add one file at a time.
The total line count is wrong at both ends
The line count splits the result string on \n and counts the pieces, so two errors live together. When a file ends in a newline the last piece is an empty string and the figure is 1 line too high, a single CRLF file shows 3 lines while the real body has 2. When a weld happens it is 1 line too low, that 24 character result above reports 3 lines where 4 is correct. So it cannot be reconciled against the line counts of the original files.
It swallows every file it is handed
No size ceiling, no format whitelist: the type restriction on the file picker never enters the logic, whatever you drop gets read. The 1 MiB scale finishes. big (1,048,576 bytes, 131,072 newlines, trailing newline present) plus that 11 byte A gives 1,048,587 characters over 131,074 lines on the default separator, and the welded line reads bravoL000000; big joined with itself on the newline separator gives 2,097,153 characters over 262,146 lines. It finishes, yet none of the three statistics is a byte count, so the size is yours to check elsewhere.
Binary behaves the same way. The 12 byte PNG header of an image/png file is read as text into 12 characters holding 1 U+FFFD and 1 lone \r; once that \r is normalised into \n the result line count moves from 4 to 5. A 9 byte 中文测试 sample read as UTF-8 turns into 8 characters and 21 bytes. Nothing here detects an encoding, it only reads.
The listing page says things the code does not do
Run every testable claim on the tool page: 12 of 17 agree, 5 conflict. The hardest is the live preview of the merge result. After changing the separator, ticking the marker and deleting an entry, the value in the result area is still 24 characters, and only another click on Merge updates it to 37; the preview follows that click rather than the controls. The other one is the separator list, which mentions newline, blank line and custom only, while the dropdown carries a fourth entry, "none", and that one is the default, the setting that welds two files together.
| What you check | Measured | Can you trust it |
|---|---|---|
| Middle line | 24 characters 3 lines | Yes, the weld is visible |
| Total characters | 15 against 13 in the output | Counted before normalisation, not a size |
| Total lines | 3 against 4 actual | Trailing newline adds 1, a weld removes 1 |
| BOM count | U+FEFF appears 0 times | Yes, it is stripped while reading |
| List order | 1 of 4 cases crossed over | Trust it only as far as you can reproduce it |
Q: The line count is wrong after a merge, what do I suspect first?
Suspect the trailing newline. Two files of 2 lines each coming out as 3, the middle line made of both bodies, means the trailing newline is missing. Switch the separator to the blank line setting and run it again: 7 lines, clean line by line.
Q: The character count in the result box disagrees with the downloaded file, what then?
Look for CRLF. The mixed batch reports 15 characters with 2 \r\n, the output is 13 characters with 0 \r\n, and the 2 missing bytes are the CR characters that got eaten. To keep CRLF in the output you must escape it yourself and save separately.
Q: Can I use these statistics to reconcile against my own files?
Only for relative differences inside one session: none of the three statistics is a byte count, the line count is wrong at both ends, and the character count is taken before normalisation, so any one of them alone misleads.
The merge step protects nothing and announces nothing. You supply the trailing newline, you settle the line order, you verify the bytes. That welded line is the only evidence that shows up by itself.