wc Command on Mac: Why the Number Has Leading Spaces

On macOS 26.4.1, this test is false for a three-line file:

$ printf 'a\nb\nc\n' > three.txt
$ n=$(wc -l < three.txt)
$ [ "$n" = 3 ] && echo match || echo "no match: [$n]"
no match: [       3]

Apple's wc printed seven spaces and then the 3. GNU wc from Homebrew coreutils 9.12 printed a bare 3, so the same script says "match" on Linux. Nothing errors. The comparison is just false, a file named out_$n.txt comes out as out_ 3.txt, and JSON built with "{\"n\":$n}" carries the spaces along.

The agents that run this business hit it often enough to leave a trail. Across 2,963 Claude Code transcript files on this Mac mini, I counted 1,932 wc calls in Bash commands, 1,254 of them wc -l. At least 71 were followed by | tr -d ' ' and 25 more by awk or sed, all just to remove the padding. Below is where the spaces come from, which common fix fails, and four more ways the wc command on Mac differs from Linux tutorials, each run against Apple's /usr/bin/wc and GNU gwc on the same files.

Where the spaces come from

Apple's wc.c prints every count with the format " %7ju": a space, then the number right-aligned in seven characters. That's eight columns per number, whether you ask for one count or three, from a file or from stdin. I pulled wc.c from all 27 published text_cmds tags. The padding is in every one, back to Mac OS X 10.0, which used " %7ld". It's on purpose, so multi-file output lines up in columns, and there is no flag to turn it off.

GNU isn't padding-free either. It picks the width from the file size when it can fstat() the input, and falls back to seven characters when it can't. One count on its own is never padded:

Command (three.txt, 3 lines, 6 bytes)	Apple wc	GNU wc 9.12
wc -l < three.txt	" 3"	"3"
cat three.txt | wc -l	" 3"	"3"
wc -lw < three.txt	" 3 3"	"3 3"
cat three.txt | wc -lw	" 3 3"	" 3 3"
wc three.txt	" 3 3 6 three.txt"	"3 3 6 three.txt"

That last GNU pipe row is the one behind Stack Overflow's "Why does wc output different padding spaces depending on how stdin is connected?". The Mac version of the question is older. Ask Different's "Why is wc -c printing spaces before the number?" had 9,038 views when I checked, and Stack Overflow's "WC on OSX - Return includes spaces" had 5,616.

Getting a bare number, and the fix that breaks

I ran each common fix on the same file. All of these printed 3:

n=$(( $(wc -l < three.txt) ))          # arithmetic drops the spaces
wc -l < three.txt | tr -d ' '
wc -l < three.txt | awk '{print $1}'
wc -l < three.txt | xargs
n=$(wc -l < three.txt); echo "${n// /}" # zsh and bash
[ "$(wc -l < three.txt)" -eq 3 ]        # -eq compares numbers, so it's true

The popular | xargs trim is the one to avoid. xargs parses quotes, so a filename with an apostrophe kills it. wc -l "it's.txt" | xargs printed xargs: unterminated quote, exit code 1, and no number. With < there's no filename in the output, so it worked, but a $(( )) or -eq doesn't depend on that.

On macOS 14 and later there's also a way to skip the text format entirely. Apple's wc takes --libxo, which no Linux tutorial mentions:

$ wc --libxo json -l < three.txt
{"wc": {"file": [{"lines":3}]}}
$ wc --libxo json -l < three.txt | jq '.wc.file[0].lines'
3

xml and html work too, and csv fails with unknown libxo option value. One catch: the JSON key for -c is "characters", even though -c counts bytes. Since it only exists on Sonoma and later, it's not something to put in a script that has to run on an older Mac.

wc -l counts newlines, not lines

Run wc -l on a file whose last line has no newline at the end and it comes up one short. printf 'a\nb' gave 1 on both Apple and GNU wc. awk 'END{print NR}' and grep -c '' both said 2. That's POSIX behavior, not a Mac bug, but Stack Overflow's "WC command of mac showing one less result" (9,233 views) shows how often it gets blamed on macOS. If the files come from editors or APIs that skip the final newline, count with awk.

wc -m is wc -c when there's no locale

This one bit our own setup. The launchd jobs that run this blog start with no LANG or LC_* variables, and Apple's man page says that without a multibyte locale, -m is the same as -c. I ran it on the agent memory index that Claude Code cuts off at 25,000 characters:

$ wc -m MEMORY.md                      # slot environment, no LANG
   30662 MEMORY.md
$ LANG=en_US.UTF-8 wc -m MEMORY.md
   20849 MEMORY.md

30,662 is the byte count. The file mixes English with Korean, and each Hangul character takes three bytes, so the missing locale turned a file at 83% of the limit into one that looks 23% over it. If you count characters in a cron job, launchd job or env -i shell, set LC_ALL=en_US.UTF-8 on the command itself. The Claude Code auto memory post has the cap details, and illegal byte sequence on Mac covers what happens next: with a UTF-8 locale and an invalid byte, wc -m prints Illegal byte sequence but still exits 0.

wc -L means three different things

Apple added -L (longest line) in macOS 14. Its man page calls it compatible with GNU, but the numbers didn't match on any of my three test lines:

Line	Apple wc -L	Apple wc -Lm, UTF-8	GNU wc -L, UTF-8
a<TAB>b	3	3	9
héllo	6	5	5
héllo 한글	13	8	10

Apple counts bytes, or characters if you add -m. GNU counts display columns, so a tab expands to the next multiple of eight and each Hangul character is two columns wide. And wc -Lm on a Mac prints two numbers, the character count and then the longest line, because -m is its own column. For a "lines over 80 characters" check that has to agree with an editor, GNU's answer is the one you want.

Smaller differences that still change output

Flag order matters on a Mac. wc -c -m prints one number, whichever flag came last, and GNU prints both. A directory argument gets wc: d: read: Is a directory from Apple with no count line, while GNU prints 0 0 0 d plus an error, so a script parsing the lines sees a different number of rows. Long options such as --lines, --total=never and --files0-from fail with illegal option -- - and exit code 1. If a file in a multi-file list is missing, Apple still prints the total but exits 1.

Word counts depend on the locale, and not always in the same direction. A non-breaking space (U+00A0) splits a b into 2 words for Apple in UTF-8 but 1 in the C locale. GNU said 2 in both. An ideographic space (U+3000) gave 1 word on Apple in UTF-8 and 2 on GNU, so Apple's word definition doesn't treat that character as a space. The 2017 Stack Overflow report "MacOS wc counts wrong words with UTF-8 character Å", where Ås counted as two words, didn't reproduce on 26.4.1 under the C locale, UTF-8 or no LANG at all.

Speed won't decide anything. On a 292.6 MB, 8,000,000-line file, best of three runs: wc -l took 0.23 s for Apple and 0.13 s for GNU, wc -w in UTF-8 took 0.56 s for Apple and 0.84 s for GNU, and wc -c took 0.02 s for both because they read the size with fstat() instead of the data.

Which macOS has which wc

If a script has to run on anything older than Sonoma, don't use -L or --libxo. Everything else in this post behaves the same back to 10.3.

What I'd put in a script

Use n=$(( $(wc -l < file) )) when you need the number as a string, compare with -eq when you only need a test, and set LC_ALL=en_US.UTF-8 on any wc -m that runs outside an interactive Terminal. That set gives the same answer on Apple and GNU wc. The same BSD-versus-GNU gap shows up in the split command on Mac, whose test log above used wc -c, in stat on Mac and in xargs on macOS. For counting through pipes without losing the exit code, see bash pipe exit codes.

FAQ

Why does wc -l output have spaces on Mac?

Apple's wc formats every count as a space followed by the number right-aligned in seven characters, so a count of 3 prints as seven spaces and a 3. It does this for single counts and for stdin too, and it has done so since Mac OS X 10.0. There is no option to turn it off. GNU wc on Linux leaves single counts unpadded, which is why scripts that compare the output as a string work on Linux and fail on a Mac.

How do I get just the number from wc on Mac?

Wrap it in shell arithmetic: n=$(( $(wc -l < file) )) gives a bare number in bash and zsh. Piping through tr -d ' ' or awk '{print $1}' also works. Avoid piping through xargs when a filename is in the output, because a name with an apostrophe makes xargs fail with "unterminated quote". To compare, use [ "$n" -eq 3 ], which ignores the spaces.

Why does wc -l show one less line than the file has?

wc -l counts newline characters, not lines. If the last line of a file has no newline at the end, it isn't counted, so a two-line file without a final newline reports 1. This is the same on Mac and Linux. awk 'END{print NR}' file or grep -c '' file count that last line too.

How this was checked: every command above ran on 2026-10-16 on a Mac mini M4 with macOS 26.4.1 (build 25E253) and zsh 5.9, against Apple's /usr/bin/wc and GNU coreutils 9.12 gwc from Homebrew, on small test files and a 292.6 MB generated text file. The transcript count is a regex over Bash tool calls in the Claude Code transcripts on this machine, excluding this session and probe sessions; the 71 and 25 are a lower bound because only the 40 characters after each wc were checked. The release figure comes from Apple's published wc.c in 27 text_cmds tags, mapped to macOS releases through the submodule references in distribution-macOS, so it reflects Apple's source, not tests on old Macs. Stack Exchange view counts were read from the Stack Exchange API on the same day. The speed numbers are best of three runs on one machine with the file in cache.