File Splitter: Split Into Parts, Merge Back Verified

A file splitter answers one question: can I get this file through the limit that is standing in its way? Email caps, upload ceilings, messaging size limits, and the occasional "files under 25 MB only" form all have a number. Splitting is how you make a 400 MB file become twenty 20 MB pieces that each fit.

The second question is the one the pages ranking for it do not answer: when the pieces come back, how do you know they are still the file you sent? Joining them back is a two-line job — concatenate — so a tool that says "byte-for-byte identical" without checking is inventing the answer. The difference between "verified" and "claimed" is a single SHA-256 digest, written down at split time and compared at merge time.

Why the manifest is the whole point

Every part the splitter writes is a plain slice of the original bytes. That is what makes the parts portable: a merger built by a completely different tool can still read them, because nothing about the format is proprietary. The catch is that plain slices are also trivial to tamper with — a part that was edited, truncated, or mis-delivered in transit looks exactly like a part that was fine. There is no way to tell the difference from the bytes alone, which is why a split without a recorded digest leaves the recipient with no way to know.

The manifest fixes that. It is a plain-text file, one line per part, in the same layout this site's hash generator reads back:

# app-image.zip — split into 4 parts of 3145728 bytes
# whole-file SHA-256: 59b3dd347144…
<part 1 digest>  app-image.zip.1
<part 2 digest>  app-image.zip.2
<part 3 digest>  app-image.zip.3
<part 4 digest>  app-image.zip.4

A human can read it. The merger parses it. When the parts come back, the digest recorded for each one is recomputed over the bytes you actually have, and the recorded whole-file digest is recomputed over the reassembled file. Match on both, and verified is a fact. Mismatch, and the row names the part that no longer hashes the way it did, so a re-download targets one file rather than the whole set.

How to split a file that has to fit a limit

Pick the part size from the limit, not from the file. Gmail allows 25 MB attachments, Outlook 20 MB, and a typical "under 25 MB" form has 25 MB in mind but counts the whole message — header, other attachments, overhead — so the safe part size is a little under it. The presets on the file splitter (1, 5, 10, 24 MB, 19 MB) map to these ceilings; 24 MB is the Gmail number, 19 MB the Outlook one.

Measured on the two fixtures above: a 9,430-byte file at a 4 MiB part size produces a single part, which is the tool's honest answer to "is this already under the limit?" — not an error. A 10 MiB file at 3 MiB per part produces four parts, three of 3 MiB and one of 1 MiB, and the plan line says so before a byte is read: "10.00 MB — at 3.00 MB per part that is 4 parts (the last is 1.00 MB)." The math is ceil(fileSize / partSize), and it is shown rather than hidden, so a person splitting a 12 GB disk image at 24 MB parts sees the number 513 before they start.

How to merge back without guessing

The merge takes the parts in any order. It orders them by the number in the filename — name.3 before name.10, so a drag-drop that lands the parts shuffled still rejoins correctly — and refuses a gap before a byte is joined: if the parts run 1, 2, 4, the answer is "Missing part 3", not a silently short file. If a manifest is pasted in and its part count does not match the files provided, the refusal says which side is wrong — "a part is missing" or "there are extra files".

Out-of-order reassembly is not a corner case, it is the test. The 10 MiB fixture above was re-joined with its parts deliberately shuffled, and the joined bytes came back byte-identical to the source — the SHA-256 of the result, 59b3dd347144…, is the one the manifest recorded. That is the same verdict a person checking a download with shasum -c reads, applied to a file that was in four pieces on the way.

What a mismatch means, and what it does not

A mismatch verdict means exactly one thing: the bytes you reassembled do not hash to the digest the manifest recorded. It does not say which transfer went wrong — a part could have been edited, truncated, or mis-delivered, or a reassembly could have used the wrong set. What it does say is where to look: the row that disagrees names itself, so the fix is to re-download that part, not to re-run the whole split. A verified verdict is the opposite of a claim — it is the recorded digest compared against the computed one and found equal, and the sentence it prints says so.

One more case the tool names instead of guessing: a merge with no manifest. The join still happens, the file still downloads, and the verdict is unverified — "no manifest was supplied, so the result is joined but not verified." That is the honest state of a merge with nothing to check against, and it is better than a green tick that a plain concatenation would print.

Why this runs in your browser

The file being split is almost always the file you do not want to upload to a stranger's server to learn what it weighs against a limit. Reading it in part-size slices keeps peak memory bounded by one part, not the whole file — a 12 GB disk image at 24 MB parts never needs more than a 24 MB window in memory — and the digests are computed as the slices are read, so the manifest is written down at split time, not reconstructed from memory at merge time. Disconnect after the page loads and the tool still works; the file never left the machine.

Wrapping up

Splitting a file is arithmetic; checking it back is not. Pick the part size from the limit that is in the way, watch the plan say how many parts it will make, and keep the manifest. When the parts come back, feed them in with the manifest, and read the verdict: verified, mismatched by name, or honestly unverified. The arithmetic was never the hard part. The digest is.

Open the file splitter — it runs in the browser, so the file you are trying to fit under a limit never leaves the machine.