How File Splitting Really Works: .001 Parts, FAT32's 4 GB Wall, and Rejoining Without Software

"Split the file into parts" sounds like a format question, but it's the one file operation that ignores formats entirely. A video, a disk image and a database dump are all split the same way, because to the splitter they're all just a long run of bytes. Knowing that makes everything else obvious: why the parts are useless on their own, why any operating system can rejoin them, and why Windows needs one specific flag to do it right.

#A file is a byte sequence, and a split is a list of ranges

Byte-splitting a 10,000-byte file into 4,000-byte parts produces three ranges: bytes 0–3,999, 4,000–7,999 and 8,000–9,999. Nothing is added: no headers, no part markers, no metadata. Joining is concatenation in order. Any tool that can append one file to another can rebuild the original exactly, and "exactly" here means bit-identical, with the same checksum as before the split.

That simplicity is also why a part can't be opened on its own. File formats keep the information needed to read them at fixed places, usually at the start, at the end, or both:

• ZIP stores its central directory, the index of every file in the archive, at the end. Part .001 has the data but no index, so archive tools can't list or extract it.
• MP4 keeps its moov atom (the index of frames and timings) either at the end or at the start, depending on whether the file was "fast-start" optimised. Part .002 of a video has frames but no index, and players reject it.
• PDF points readers to its cross-reference table from the very last bytes of the file (startxref), so only the final part has it, and that part lacks the pages.

If the person receiving the pieces needs each one to be usable by itself, byte-splitting is the wrong tool. Use a format-aware split instead: PDF pages, CSV rows, video clips, audio tracks.

#Names: why .001, and why the zero-padding matters

The name.ext.001, .002, … convention came from tools like HJSplit and was cemented by 7-Zip, whose "Split file" command and volume archives (archive.7z.001) use the same scheme. Zero-padding isn't cosmetic. Shells and file managers sort names as text, so without it, file.10 sorts before file.2. A wildcard join like cat file.* would then rebuild the parts in the wrong order and corrupt the result silently. Three digits cover 999 parts. Past that, the padding should grow to four digits for every part, so the names still sort correctly.

#Not every "split archive" is a raw split

Three formats that look alike behave differently:

Concatenating RAR volumes or spanned ZIPs produces a file no tool can open. Only the first two rows are plain byte splits.

#The limits you're probably splitting around

FAT32 catches people every week. USB sticks and SD cards often ship formatted as FAT32 for compatibility, and copying a 4.7 GB video or ISO to one fails ("The file is too large for the destination file system" on Windows; "too large for the volume's format" on macOS) even when the stick has 60 GB free. The file size is stored in a 32-bit field, so the largest representable size is 2³² − 1 bytes. Split into parts of exactly that size, or reformat the drive as exFAT if every device that will read it supports exFAT.

Email is worse than the number suggests. Attachments travel as base64, which turns every 3 bytes into 4 characters and then wraps lines at 76 characters plus a 2-byte CRLF: 4/3 × 78/76 ≈ 1.368. A 25 MB limit fits roughly 18 MB of actual file. The arithmetic is worked through in our attachment-limit guide.

#Rejoining on any system, and the Windows trap

7-Zip (any OS with a port): open file.ext.001 and extract. 7-Zip detects the numbered parts and joins them.

macOS / Linux:

cat "video.mp4."??? > "video.mp4"

The shell expands ??? to the three-digit suffixes in sorted order, which is exactly why padding matters. Keep the wildcard outside the quotes.

Windows Command Prompt:

copy /b "video.mp4.001" + "video.mp4.002" + "video.mp4.003" "video.mp4"

The /b is not optional. Without it, copy treats the sources as text when combining files: it stops reading each source at the first Ctrl+Z byte (0x1A), the old DOS end-of-file marker, and appends a 0x1A to the output. Binary files are full of 0x1A bytes, so a join without /b silently produces a truncated, corrupt file. One more limit: a single cmd line tops out at 8,191 characters, so for hundreds of parts use 7-Zip or a joiner tool instead of one long command.

#Verifying the join: CRC-32 vs SHA-256

After a transfer you need to know that every byte survived. Two approaches cover different threats:

• CRC-32, the checksum in ZIP files and .sfv (Simple File Verification) lists. It's designed for accidental corruption: it detects every burst error up to 32 bits long, and random corruption slips through with a probability of about 1 in 4.3 billion. An .sfv file is plain text, one line per part (video.mp4.001 3A9F04C2), and it tells you which part to re-send. QuickSFV, RapidCRC and the split.tools joiner all read it.
• SHA-256 guards against deliberate tampering, which CRC-32 can't do: anyone can forge a file with a chosen CRC. Use it when the source is untrusted. certutil -hashfile video.mp4 SHA256 on Windows, shasum -a 256 video.mp4 on macOS, sha256sum video.mp4 on Linux.

For "did my USB copy or upload finish intact," CRC-32 per part is the practical choice: it's fast, and it localises the failure.

#Why splitting in a browser is instant

Server-based splitters have to receive the whole file before they can cut it. That's around 27 minutes for 4 GB over a 20 Mbps upstream, and that's before your file sits on someone else's disk. A browser can do better than both, because of one API: blob.slice(start, end). A dropped file is a Blob, and slicing it returns a reference to a byte range without reading any bytes. The split.tools file splitter builds every part this way, so splitting a 10 GB file takes milliseconds and almost no memory. The bytes stream straight from your disk only when a part is saved, and the folder save in Chromium browsers writes them out one by one.

The one step that does read the whole file is the optional checksum pass that writes the .sfv. CRC-32 runs at disk speed in a streaming loop, so even multi-gigabyte files take seconds to tens of seconds.

#When not to byte-split

• The recipient needs to open pieces individually. Use a format-aware splitter.
• The data compresses well (logs, CSVs, uncompressed images). A 7z or ZIP archive with volumes compresses and splits in one step. Byte-splitting an already-compressed video or JPEG loses nothing, but splitting a 5 GB log without compressing it wastes bandwidth.
• You need the file to survive a missing part. Raw splits have no redundancy: lose one part and the rest are useless. Archive formats with recovery records (RAR's recovery volumes, PAR2 files) can rebuild missing pieces.

For everything else (moving a big file across a size limit and putting it back together exactly), a plain byte split is the most portable format there is. Any machine made in the last forty years can join it with tools it already has.