split Command on Mac: -n From a Pipe Makes 16 KB Chunks

On macOS 26.4.1 I piped a 5,000,000-byte file into split -n 4, expecting four parts of 1,250,000 bytes. I got 16,384, 16,384, 16,384 and 4,950,848 bytes, and exit code 0. Five runs gave the same four sizes. The same file split evenly when I passed it with < instead of a pipe, and GNU gsplit split the piped version evenly too.

That's the quietest of five ways the split command on Mac differs from the one in Linux tutorials. I ran each on the Mac mini that runs this business, against Apple's /usr/bin/split (text_cmds-199) and Homebrew's GNU gsplit 9.12. Then I read Apple's split.c for every macOS release to see which of them depend on your version.

Trap 1: split -n on a pipe sizes the chunks from what's buffered

Apple's split.c handles -n in a function called split3(). It calls fstat() on the input and divides st_size by the chunk count. For a regular file that's the file size. For a pipe it's however many bytes happen to be waiting in the pipe at that moment (65,536 here, judging by the 16,384-byte parts). The first n-1 files get that small size, and the last file gets everything else:

$ cat r5m.bin | split -n 4 && wc -c x*
   16384 xaa
   16384 xab
   16384 xac
 4950848 xad
 5000000 total
$ split -n 4 < r5m.bin && wc -c x*
 1250000 xaa
 1250000 xab
 1250000 xac
 1250000 xad

It looks fine in a quick test. cat ten.txt | split -n 2 on a 21-byte file worked, because all 21 bytes were in the pipe before split looked. When the writer is slower, the pipe is empty at that moment and you get an error instead. Both (sleep 1; seq 1 10) | split -n 2 and seq 1 100000 | split -n 4 failed with split: can't split into more than 0 files, exit code 1. That's the better outcome, because you notice it.

Fix: give split -n a file path or a < redirect, never a pipe. If the data has to come from a pipe, write it to a temp file first or use gsplit -n, which handled the same pipe correctly.

Trap 2: it stops at 100 numbered files and keeps the partial output

On Linux, split -l 1 -d on a 150-line file gives 150 files. GNU widens the suffix when it runs out: after x89 it goes to x9000, so the names still sort in order. Apple's split doesn't. It stopped at x99:

$ seq 1 150 > l150.txt
$ split -l 1 -d l150.txt; echo "rc=$?"
split: too many files
rc=65
$ ls | wc -l; cat x99
     100
100

Lines 101 to 150 were never written, and the 100 files it did make stay on disk. With letters the limit is 26 × 26 = 676: a 1,000-line file stopped at xzz. A script that checks the exit code will catch it. A script that runs split and then cat x* | wc -l in a later step won't, unless someone counts.

The widening code is in Apple's file. It's turned off with #ifdef __APPLE__ autosfx = false;, and the FreeBSD habit of treating -a 0 as "widen as needed" is wrapped in #ifndef __APPLE__. On 26.4.1, -a 0 just means two characters. The fix is to size the suffix yourself: -a 3 gives 1,000 numbered names, and -a 3 without -d gives 17,576.

Trap 3: the GNU options people paste from Linux

These failed with a usage message and exit code 64 on 26.4.1:

GNU command	Apple split result	What works on a Mac
split -n l/3 f	l/3: number of chunks is invalid	split -l $(( ($(wc -l < f) + 2) / 3 )) f
--additional-suffix=.txt	illegal option -- -	rename after: for p in x*; do mv "$p" "$p.txt"; done
--numeric-suffixes	illegal option -- -	-d (macOS 12.3 and later)
split -C 100 f	illegal option -- C	no equivalent; gsplit -C
split -b 1.5M f	1.5M: byte count is invalid	-b 1536k

Plain -n 3 is accepted, but both versions cut by bytes. On a 10-line file the first part ended with 4 and the next started with the newline, so every chunk boundary split a line. Apple has no line-aware mode. The wc -l arithmetic above gives line-aligned parts.

Units are the other quiet difference. split -b 1MB made 1,048,576-byte parts on the Mac; gsplit -b 1MB made 1,000,000-byte parts. Apple reads M and ignores the B. GNU treats MB as decimal. Both exit 0.

Trap 4: split -b 4G is one byte too big for FAT32

The most common reason to split a file on a Mac is a FAT32 USB stick, which can't hold a file of 4 GiB or more. I made a 10 GB FAT32 disk image with hdiutil and a 4,500 MB file, then tried the obvious command:

$ split -b 4G src.bin; ls -l xaa
-rw-r--r--  1 sg-mini  staff  4294967296  xaa
$ cp xaa /Volumes/SPLITFAT/
cp: /Volumes/SPLITFAT/xaa: fcopyfile failed: File too large
$ ls -l /Volumes/SPLITFAT/xaa
-rwx------  1 sg-mini  staff  4293918720  xaa

4G means 4,294,967,296 bytes. FAT32's limit is one byte less. The failed copy also left a cut-off 4,293,918,720-byte xaa on the stick, which you have to delete before retrying. split -b 4095m made parts that copied with exit code 0, and cat of the parts matched the original byte for byte (cmp exit 0). If you need a stick formatted first, I compared the options in how to format an external SSD for Mac.

Trap 5: your macOS version decides which flags exist

Apple publishes each release's source in distribution-macOS. I mapped all 166 release tags to the text_cmds version they contain and fetched split/split.c from all 27 text_cmds tags. There are six different files, covering 163 releases from Mac OS X 10.0 to macOS 26.5. Three tags (10.0.1 to 10.0.3) have no text_cmds entry.

Two older details are easy to miss. -a only exists from 10.4. And until 12.2, -b took only a lowercase k or m, so a FAT32 recipe written for a current Mac fails on an older one with illegal byte count. In 14.0 Apple also replaced a fixed buffer in the -p code with getline(), so very long lines are handled differently before and after that release.

The version line shows up in the questions people ask. I searched four Stack Exchange sites for questions with "split" in the title that mention a Mac. Four are about Apple's split options: -d and --additional-suffix (2016, 922 views), -C to split by bytes but keep lines (2017, 5,721 views), -n l/2 from a Linux script (2017, 2,274 views) and rejoining split -b 20mb parts on Windows (2017, 2,692 views). The usage message quoted in the first two has -p but no -d or -n, which matches the 10.5 to 12.2 source. On 26.4.1 the 2016 command still fails, now on --additional-suffix instead of -d. The -C and -n l/2 questions still have no Apple answer.

What I'd use

For scripts that run on both Linux and Mac, I'd keep to -l, -b with a whole number and a lowercase k or m, and an explicit -a big enough for the file count, and check the exit code. That set works on every release since 10.4 and on GNU. To rejoin the parts, cat x* > out is safe because the names sort in order, as long as no other file in the folder starts with x. Anything else, use gsplit by name rather than putting GNU first in your PATH.

The same BSD-versus-GNU gap shows up in mktemp on macOS, head's illegal line count and shuf on Mac. If you're splitting a zip rather than a raw file, zip -s has its own problem when you rejoin, which I measured in zip command on Mac.

FAQ

How do I split a file into parts on a Mac?

Use the built-in split command in Terminal. split -b 100m bigfile part_ makes 100 MiB pieces named part_aa, part_ab and so on, and split -l 1000 file.csv makes 1,000-line pieces. On macOS 12.3 and later, add -d for numbered names and -n 4 for four equal pieces, but give -n a file, not a pipe. Rejoin with cat part_* > bigfile.

Why does split say "too many files" on Mac?

Apple's split never adds suffix characters. With the default two characters it stops after 676 letter names (xaa to xzz) or 100 numbered names (x00 to x99 with -d), exits with code 65, and leaves the files it already wrote. Set a longer suffix with -a, for example -a 3 for up to 1,000 numbered or 17,576 letter names, or use GNU gsplit, which widens the suffix on its own.

How do I split a file for a FAT32 USB drive on Mac?

Use split -b 4095m file part_ rather than -b 4G. FAT32 can't store a file of 4 GiB (4,294,967,296 bytes) or larger, and a 4G part fails to copy with "File too large" while leaving a truncated copy on the drive. 4095m parts copy normally, and cat part_* > file rejoins them. The G suffix only works on macOS 12.3 and later anyway.

How this was checked: I ran every command above on 2026-10-16 on a Mac mini M4 with macOS 26.4.1 (build 25E253) and zsh 5.9, using Apple's /usr/bin/split (text_cmds-199) and GNU coreutils 9.12 gsplit from Homebrew. The FAT32 test used a 10 GB sparse disk image formatted MS-DOS FAT32 by hdiutil, not a physical stick. The release table comes from Apple's published split.c in 27 text_cmds tags, matched to macOS releases through the submodule references in distribution-macOS, so it shows what Apple's source says, not tests on old Macs. The Stack Exchange search was a title search for "split" plus "mac" on Stack Overflow, Unix & Linux, Super User and Ask Different on the same day; questions that don't name split in the title aren't included. The 65,536-byte pipe figure is inferred from the 16,384-byte chunks, not read directly. All test files were deleted afterward.