How to Compare Binary Files on Mac — Complete Hex Diff Guide 2026

Binary comparison works at the byte level: instead of comparing lines of text, it finds every single byte that differs between two files, showing you the exact offset, the old value, and the new value. Unlike text diff, binary diff works on any file format — executables, firmware blobs, compiled output, images, databases, serialized data — as long as it has bytes, binary diff can tell you what changed.

Why Binary Comparison Matters

Several day-to-day scenarios make binary diff an essential tool:

Firmware update verification: When you download a new firmware version, you want to know exactly which byte regions changed — not just trust the version number. Comparing old and new .bin or .img files at the byte level lets you verify that changes are in the expected sections and nothing unexpected was modified.

Reproducible build checking: Rust, C++, and Go builds should ideally be bit-for-bit identical across machines and time. But embedded timestamps, linker ordering, and path strings can introduce subtle differences. Binary diff quickly identifies which ELF section (.rodata, .debug_info) is introducing the inconsistency.

Malware and security analysis: Security researchers compare clean executables against modified versions to find injected code by offset. Even for regular developers, verifying a downloaded binary against an official checksum is good practice — and binary diff is the tool that tells you where they differ if they don’t match.

Asset and backup integrity: PNG, JPEG, PDF, SQLite .db files can look identical visually but have byte-level differences after sync or transfer. Binary diff gives you ground truth about whether a backup is truly identical to the original.

Compiled Protobuf / binary serialization formats: When two versions of a serialized binary payload differ, binary diff narrows down which byte region is the source of the discrepancy, saving significant debugging time.

Tool Comparison Table

Quick recommendation: for the most intuitive GUI with color-coded diff, use Lode; for a no-install Terminal solution, use xxd + diff; for a fully-featured free hex editor, use HexFiend. FileMerge is not suitable for binary files — it will error out or display garbled output.

Method 1: Lode Binary Diff (Recommended)

Lode is a native macOS application (Tauri 2 + Rust) that integrates six work modes — including Binary Compare and Hex View — in a single app. The Binary Diff mode uses a side-by-side two-column layout, showing each file’s hexadecimal values alongside their ASCII representation, with differences highlighted in real time. No conversion step required.

Step-by-Step Walkthrough

Step 1: Open Lode and select Binary Diff mode

Launch Lode from your Dock or use Spotlight (⌘Space, type “Lode”). In the mode selector at the top, click Binary Diff (some builds label it Hex View).

Step 2: Load the two binary files

Drag the first binary file onto the left panel and the second onto the right panel. Alternatively, use File → Open to select each file. Lode handles files of any size through Rust async I/O — large firmware blobs or database files load without freezing the UI.

Step 3: Read the hex diff output

Lode displays each file in the standard hex editor format: a hex offset column on the far left, 16 bytes per row in hex, and an ASCII representation on the right. Differences are highlighted with three distinct colors:

The offset shown (e.g., 0x000012A0) tells you the exact byte position from the start of the file — the number you need for a bug report or patch note.

Step 4: Navigate between differences

The right sidebar shows diff navigation arrows. Use ⌘↓ to jump to the next changed region and ⌘↑ to go back to the previous one. For large binaries with hundreds of differences, this navigation saves significant manual scrolling.

Step 5: Export or copy hex values

Right-click any highlighted region to copy the hex values, decimal offset range, or ASCII-decoded string. This makes it easy to paste exact byte positions into a bug report, Slack message, or patch note.

Why Lode’s alignment is correct

Most text diff tools, when forced onto binary data, produce misleading output: a single inserted byte causes every subsequent row to appear as “different” because the line boundaries shift. Lode’s Binary Compare uses an LCS (Longest Common Subsequence) algorithm to align the two files before highlighting, so an insertion is shown as an insertion rather than corrupting the alignment of everything after it.

Method 2: Terminal — xxd + diff

macOS ships with xxd, a utility that converts any binary file into a readable hex dump. Combining it with diff gives you a basic binary comparison without installing anything:

xxd /path/to/file1.bin > /tmp/a.hex
xxd /path/to/file2.bin > /tmp/b.hex
diff /tmp/a.hex /tmp/b.hex

xxd output looks like this:

00001200: 4865 6c6c 6f20 576f 726c 6400 0000 0000  Hello World.....

Each row shows 16 bytes: the left column is the hex offset, the middle is the hex values (grouped in pairs), and the right is the ASCII representation (non-printable bytes shown as .).

diff output marks lines with < (from file1) and > (from file2). You can read the offset from the start of each row.

Limitations of the Terminal approach

• No color: output is monochrome text, hard to scan visually for large diffs.
• Insertion alignment breaks: if file2 has extra bytes inserted relative to file1, diff marks everything after the insertion as different, even if it’s actually the same content shifted by a few bytes.
• Conversion overhead: xxd writes a temporary text file roughly 3x the size of the original binary.
• No interactive search: finding a specific hex pattern requires piping through grep.

For a quick existence check (same or different, no detail needed), cmp file1 file2 is faster — it exits with no output if files are identical, or reports the first differing byte position.

Method 3: hexdump -C

hexdump -C is an alternative to xxd with a slightly different output format:

hexdump -C /path/to/file1.bin > /tmp/a.hex
hexdump -C /path/to/file2.bin > /tmp/b.hex
diff /tmp/a.hex /tmp/b.hex

The -C flag produces the canonical hex+ASCII format: 16 bytes per line, hex offset at left, ASCII at right. Usage and limitations are essentially the same as xxd + diff. The main practical difference is that xxd supports a round-trip back to binary (xxd -r), which is useful if you need to patch specific bytes. Choose based on your preference or the tooling available on your target system.

Method 4: HexFiend

HexFiend is the leading free, open-source hex editor for macOS, with native Apple Silicon support. It uses streaming reads to handle multi-gigabyte files without loading the entire content into memory.

HexFiend’s Tools → Compare Files feature provides a side-by-side hex view with difference highlighting — similar in concept to Lode’s Binary Diff. If your primary need is hex editing (changing specific byte values), HexFiend is the right tool: Lode’s Binary Diff is read-only comparison, not an editor.

HexFiend vs Lode: when to pick which

• Need to edit bytes at specific offsets → HexFiend
• Need binary diff integrated with folder compare and full-text search in one workspace → Lode
• Need only binary diff with no other features → both work; personal preference

Rex’s Personal Experience

During Lode development, I frequently needed to verify that Rust-compiled binaries were deterministic across builds. The theory is that deterministic builds produce bit-for-bit identical output — in practice, I ran into cases where .debug_info sections embedded absolute build-path strings, causing the binary to differ between machines even when the source was identical.

Using Lode’s Binary Diff to compare two builds of lode (the macOS executable inside the .app bundle) immediately showed the differing byte region, which I could then cross-reference with nm or dwarfdump to identify the specific debug symbol. The key advantage over xxd + diff was alignment: the path string differences were surrounded by identical bytes, and xxd + diff kept breaking alignment at every insertion point, making the output nearly unreadable. Lode’s LCS-based alignment kept the surrounding identical content in sync, so only the actually-changed bytes were highlighted.

I also use binary diff when working with firmware blobs — dragging old and new versions of a .bin file into Lode’s Binary Diff takes a few seconds to parse, then gives me a clear visual map of which byte regions changed and which are untouched. This is much faster than reading changelogs to figure out which firmware version introduced a specific behavior change.

Frequently Asked Questions

Q: How do I compare two binary files in macOS Terminal?

Use xxd to convert both files to hex dumps, then diff them: xxd file1 > /tmp/a.hex && xxd file2 > /tmp/b.hex && diff /tmp/a.hex /tmp/b.hex. For a simple same/different check without detail, use cmp file1 file2 — no output means identical.

Q: Is there a free hex diff tool for Mac?

Yes — two good ones. Lode provides an integrated Binary Diff mode alongside folder compare and full-text search. HexFiend is a dedicated hex editor with a Compare Files feature. Both are free, open source, and native on Apple Silicon.

Q: What’s the difference between binary diff and text diff?

Text diff operates on lines of text — it will output Binary files differ and stop when it encounters non-text content. Binary diff operates on individual bytes, reporting the exact offset and value change for every byte that differs, regardless of file format. Binary diff works on executables, images, databases, and any other non-text file.

Q: Can Lode open large binary files?

Yes. Lode’s binary read backend uses Rust async I/O with streaming reads, so it does not load the entire file into memory at once. Multi-hundred-megabyte firmware blobs or large SQLite database files open and diff without blocking the UI.