Splitting a File That Is Too Big to Send

A byte cut, not a content cut

The tool reads the file as a stream of bytes and cuts it at fixed intervals. It never asks what the bytes mean, which is exactly why it works on anything — a video, a database dump, an archive, a disk image — and exactly why the pieces are inert. A file format is a structure: a header at the front, an index somewhere, and content that refers to both. Cut it in three and the first piece has a header describing content it no longer contains, while the last has content nothing points at.

The compensation is that the operation is perfectly reversible. Nothing is interpreted, so nothing can be misinterpreted: concatenating the parts in order gives back precisely the bytes that went in, and the result is the original file rather than a copy of it. That is a stronger guarantee than most file operations offer, and it is the reason splitting is a reasonable last resort rather than a desperate one.

The megabyte you set is not the megabyte the limit means

Chunk sizes here are mebibytes: a value of 10 means 10 × 1024 × 1024 = 10,485,760 bytes. A service that advertises a 10 MB limit usually means 10,000,000, so a chunk set to exactly the limit overshoots it by 4.86% and is refused, which is a confusing failure because the number on screen matches the number in the rule. The proportion is the same at every size, so 25 becomes 26,214,400 against a 25 MB ceiling, and 50 becomes 52,428,800.

Leave a margin rather than doing the conversion in your head. Nine against a ten-megabyte ceiling and twenty against twenty-five are comfortable, and the slack does a second job: an email attachment is encoded for transport, which adds roughly a third to what leaves your machine, so a part that only just fits on disk may not fit in a message.

Order is everything, and nothing warns you

The parts carry no marker saying where they belong; their position lives entirely in their names. Join them in the wrong sequence and you do not get an error — you get a file of exactly the right size that is complete nonsense, and whatever opens it will report corruption rather than a wrong order. Tell the recipient to keep the names, and use two digits from the start if there might be more than nine parts, for the same sorting reason that scrambles merged PDFs.

Three things to try before splitting

Compress first, because a file that fits needs no explanation on the other end. Then consider a link: most people now have somewhere to put a file and send an address, and a recipient who clicks a link has succeeded, while a recipient who must join three parts may not. Then split the content rather than the bytes — pages, chapters, tracks, a folder of images sent in three folders. Content splits produce pieces that each open, which is the difference between sending something usable and sending a puzzle.

Frequently asked questions

Can the recipient open part one on its own?

No, and it is worth saying so in the message rather than letting them discover it. The cut is at a byte position with no regard for structure, so part one of a video has a header and no index, part one of an archive has a catalogue describing files that are not there, and part one of a PDF has a beginning with no cross-reference table. Every piece needs every other piece.

Is the rejoined file identical to the original?

Byte for byte, provided the order is right and no part is missing. Nothing is decoded or re-encoded at either end, so there is no generation of loss and no interpretation to get wrong. If you want certainty, compare the size of the rejoined file with the size of the original — a mismatch means a part is missing or duplicated, and a match with a corrupt result means the order was wrong.

Should I zip the file before splitting it?

Only if it is the kind of data that compresses — a database export, source code, logs, uncompressed text. If it is already a video, an image, an audio file or a PDF, the archive will save a percent or two and add a step for the recipient. Where a zip does help is packaging: one archive split into parts is tidier than a folder of loose files split individually, and the recipient joins once instead of many times.

The recipient uses a different operating system. Does that matter?

Not for the bytes — a concatenation is a concatenation everywhere. It matters for how they do it: the command differs between systems, and a browser-based joiner avoids the question entirely by working the same in every browser. Sending a one-line instruction along with the parts is the difference between a recipient who succeeds in a minute and one who writes back.

How many parts is too many?

Past three or four, the failure rate on the other end climbs faster than the convenience. A 700 MB file at 20 mebibytes a part is 34 attachments, which is not a delivery but a chore, and one missing piece invalidates all of them. At that point a link is the honest answer. Splitting earns its place when a file is a little over a limit, not when it is many times over.