Understanding file splitting
One big file, many smaller ones, byte-exact.
Why splitting is sometimes the answer, the byte-level operation behind it, and the rejoin step that needs the order right.
The split operation.
Splitting takes one file of N bytes and writes M smaller files whose concatenated contents are byte-for-byte identical to the original. The standard naming convention appends a sequential suffix (file.001, file.002, etc.) or letter (aa, ab, ac...). Unix split, FFS HJSplit, WinRAR's volume archives — all do this. No compression, no transformation — pure byte-level partition.
Why bother in 2026.
Email attachment limits (Gmail 25 MB, many corporate gateways 10-25 MB). USB drives with FAT32 still around (4 GB file size limit, surprises in 2026). Cloud uploads that occasionally fail mid-transfer and need to be resumed at the chunk level. Burning to optical media that has fixed sizes (CD 700 MB, DVD 4.7 GB). Most modern transports don't need this, but the corners where they do are still common enough to make file splitting useful.
A worked split.
A 5 GB video file, 25 MB email limit. Unix: split -b 24M video.mp4 video.part. produces video.part.aa, video.part.ab ... 209 chunks at 24 MB each (the 25 MB limit is wire-protocol; 24 MB raw allows for encoding overhead). Rejoin: cat video.part.* > video.mp4. Wildcards in shell expand in alphabetical order, which is the right order. Same operation on Windows uses copy /b video.part.* video.mp4.
Split → rejoin
split -b 24M file out. ; cat out.* > rejoined
Bytes in, bytes out — identical to the original.
5 GB file → 209 parts at 24 MB ; cat * recovers it
= md5 matches original
Splits with integrity checks.
A split + rejoin without integrity check is fine until one chunk gets corrupted in transit and the rejoined file silently differs from the original. Always ship a hash file with the chunks: an SHA-256 of the original, computed before split. After rejoin, verify the hash. ZIP volumes (split archives) carry per-volume checksums built in; bare-byte splits don't. The extra step is cheap and catches everything.
Don't split compressed archives that need random access.
A split RAR archive lets you extract files even when you only have the first few parts (provided the file you want lives in those parts). A split tar.gz doesn't — the gzip stream needs all parts in order, no random access. If the splitting is just for transport (assemble all the parts at the destination, then extract), either format works. If you might need to extract from partial chunks, use a real split-archive format (RAR, 7z) that supports it.
Modern transports avoid the need.
Most modern file transfer (S3 multipart upload, rsync, cloud sync clients, BitTorrent, WebRTC data channels) does chunked transport internally. The user sees one file; the protocol splits it for transmission and reassembles at the other end. File splitting as a manual user operation is a workaround for transports that don't do this on their own — email attachments and FAT32 USB sticks being the prime culprits.