xxd on Mac: Already Installed, but Which of 7 Versions?

The top Google suggestion for "xxd mac" is "install xxd mac". You don't need to install it. On the Mac mini that runs this business, type -a xxd finds exactly one copy, /usr/bin/xxd, and xxd -v prints xxd 2025-08-24 by Juergen Weigert et al. Apple ships it as part of its vim build on macOS 26.4.1 (build 25E253). The real question is which xxd you have, because a Mac that is a few releases older has a different one with different options.

To answer that, I read the xxd.c from all 42 tags of Apple's open-source vim project and mapped 56 macOS releases to those tags through the distribution-macOS repository. Then I ran the parts people get wrong on this machine.

Is xxd built into macOS?

Yes. It isn't a separate package. xxd is a small C program that lives in vim's source tree under src/xxd/, and Apple's vim project has carried it in every tag I could read, back to vim-10 (the build for Mac OS X 10.3.9). In the Stack Exchange API, 86 Stack Overflow questions have "xxd" in the title, with 460,637 views between them. Seven of them are about xxd being missing, and none of those seven are on a Mac. Four are Windows (cmd or PowerShell), and the other three are Fedora, a Yocto build and a VS Code terminal on Ubuntu. On Linux, xxd comes in a vim package that a minimal install may not include. Only one of the 86 titles mentions a Mac at all.

Homebrew has no xxd formula (brew search xxd returns xxh, xsd and two unrelated names). If you want a newer one, it comes with Homebrew's vim, 9.2.1150 today. That tag's xxd.c says xxd 2026-06-16, which is the same as vim's master branch. The install steps and the PATH trap that keeps /usr/bin/vim in front are in how to update vim on Mac.

Which xxd your macOS version ships

The version string sat at V1.10 27oct98 for a long time while options were added underneath it. Then it started moving with each vim update. Across 10.11 to 26.5 there are seven distinct strings:

The option dates matter more than the version strings, because they decide whether a script copied from a newer machine runs at all:

Option	What it does	First macOS with it	Apple tag
-e, -o off	little-endian groups; add an offset to displayed positions	10.12	vim-62
-C	capitalize variable names in -i output	10.15	vim-78.11.1
-d	decimal offsets	12.0	vim-97.40.2
-p -c 0	plain hex on one line, no wrapping	12.3	vim-106
-n name	set the array name for -i	13.0	vim-124
-R when	color output, default auto	14.1	vim-149
-t	add a terminating null to -i output	not shipped	upstream only

One Stack Overflow question backs up the old end of the table. In "xxd converts hex file to 32 bytes binary on Mac, 30 bytes on busy box?" (2,390 views), the asker pasted xxd V1.10 27oct98 from Big Sur. My map puts every 11.x release on that string. The only tag I couldn't read, vim-91.100.1 (11.3 to 11.5), sits between two tags that both say V1.10. The fault in that question was BusyBox's xxd, whose -c default cuts the output at 30 bytes. Apple's xxd wrote all 32.

Five things that go wrong, tested on 26.4.1

1. xxd -r on plain hex writes nothing. Without -p, reverse mode expects the full dump format with an offset column. Plain hex gives 0 bytes and exit code 0, so a script doesn't notice. One Stack Overflow question has exactly this title, "put some hex string to xxd using stdin does not generate any output" (8,995 views).

$ echo 48656c6c6f0a | xxd -r | wc -c
       0
$ echo 48656c6c6f0a | xxd -r -p
Hello
$ printf '48 65\n6c 6c 6f\n' | xxd -r -p     # spaces and newlines are skipped
Hello

2. -p wraps at 30 bytes. 64 zero bytes come out as three lines of 60, 60 and 8 hex characters. Anything that compares the result to a single string, such as a hash or a key, needs one line. xxd -p -c 0 gives you that on 12.3 and later. On older releases, the source rejects any column count below 1 with invalid number of columns (max. 256), so use xxd -p | tr -d '\n' if a script has to run on Monterey 12.2 or earlier.

3. xxd -r into an existing file patches it. It doesn't truncate. I wrote hello world to a 12-byte file and reversed a one-byte dump into it:

$ printf 'hello world\n' > p.txt
$ echo '00000000: 4a' | xxd -r - p.txt
$ cat p.txt; wc -c < p.txt
Jello world
      12

That's useful for binary patching, and a surprise if you expected a new file. The offset column is used even when you write to stdout. A dump that starts at 00000010: came back as a 17-byte file with 16 zero bytes in front.

4. -i names the array after the path. xxd -i dir/my-file.bin declares unsigned char dir_my_file_bin[] and dir_my_file_bin_len. When the input comes from stdin you get only the bytes, with no declaration. -n blob fixes the name, but only on 13.0 and later. If you're embedding a file into a C build and need it null-terminated, upstream's new -t isn't on any macOS yet. On 26.4.1, xxd -i -t prints the usage text and exits 1.

5. Exit codes aren't what a wrapper expects. xxd -h exits 1 after printing help, a missing input file exits 2, and an unknown option exits 1 with the same usage text. A script that probes for xxd with xxd -h && … will decide it's broken. Use command -v xxd or xxd -v, which exits 0.

xxd vs hexdump vs od on a Mac

macOS also ships BSD hexdump and od. They show the same bytes in different layouts. hexdump -C gives the canonical offset, hex and ASCII view, and od -An -tx1 gives bare hex bytes. Neither one can go back from hex to binary. That's the reason to use xxd. Speed is the other reason. On a 50,000,000-byte file of random data, with output sent to /dev/null:

Command	Wall time
xxd	0.97 s
xxd -p	2.10 s
od -An -tx1	2.42 s
hexdump -C	6.39 s

I didn't expect plain mode to be twice as slow as the full dump. It's one run on one machine, so read it as a ranking, not a benchmark. A round trip through either format (xxd | xxd -r and xxd -p | xxd -r -p) gave back a 100,000-byte random file that cmp called identical. For checksums, use shasum rather than piping through xxd. The Mac-specific differences are in sha256sum on Mac, and base64 on Mac covers the other encoder people move between machines. A file that xxd shows as all zeros is also the cause of one of the errors in zsh: exec format error.

FAQ

Is xxd installed on Mac by default?

Yes. macOS includes xxd at /usr/bin/xxd as part of Apple's vim build, so there is nothing to install. macOS 26.1 through 26.5 ship xxd 2025-08-24. Releases before macOS 12.3 ship the much older xxd V1.10 27oct98, which lacks options such as -p -c 0 and -n. Run xxd -v to see which one you have.

How do I convert hex to binary with xxd on Mac?

Use xxd -r -p, for example echo 48656c6c6f | xxd -r -p > out.bin. The -p flag is required for plain hex. Without it, xxd -r expects the full dump format with an offset column, writes 0 bytes and still exits 0. Spaces and newlines in the hex input are ignored.

What is the difference between xxd and hexdump on Mac?

Both print a file's bytes in hex, but only xxd can reverse a hex dump back into binary with xxd -r. hexdump is the BSD tool, and hexdump -C gives the classic offset, hex and ASCII layout. On a 50 MB file, xxd took 0.97 seconds and hexdump -C took 6.39 seconds on a Mac mini M4.

How this was checked: the commands and timings were run on 2026-10-15 on a Mac mini M4 running macOS 26.4.1 (build 25E253), using Apple's /usr/bin/xxd. The version table comes from downloading src/xxd/xxd.c (vim/src/xxd/xxd.c in older tags) for all 42 tags of apple-oss-distributions/vim. 41 were readable and vim-91.100.1 had no xxd.c at either path. I took the version string and the options listed in the usage text from each file. macOS releases were mapped to tags through the vim submodule pointer in 56 distribution-macOS release tags, from 10.3.9 to 26.5. This shows what Apple published as source for each release. I only checked the installed binary on this one Mac, where it matches its tag. Stack Overflow counts come from a Stack Exchange API title search for "xxd" on the same day, with titles classified by keyword.