How to compare two folders on a Mac, step by step

Finder cannot compare two folders. There is no menu item for it, and no view that lines two folders up and marks what differs. On a Mac the job is done one of three ways: with commands that already ship with macOS, with FileMerge from Xcode, or with a dedicated comparison app. The commands cost nothing and answer most questions in under a minute. A comparison app earns its place when the result is hundreds of differences that each need a decision.

The short version, for anyone in a hurry:

1. Open Terminal and run diff -rq -x .DS_Store /path/to/A /path/to/B. It lists files present on one side only and files whose contents differ.
2. If the folders are large, compare lists of names first, then contents.
3. Do not treat a plain rsync -n dry run as proof that two folders match. The test below shows why.

What "the same" has to mean before anything is run

Most comparisons go wrong because the question was never stated. There are three different questions, and each needs a different check.

Question	What has to be read	Typical cost
Is the copy complete and intact?	Every byte of every file	Proportional to total size
Which side has the newer work?	Names, sizes, modification dates	Seconds, even on large trees
What changed inside these documents?	File contents, line by line	Slow, needs a viewer

The first is verification, for example after copying a project to an external drive. Only a full read of both sides answers it. The second is triage between two working copies, say a laptop and a desktop. Reading every byte here wastes time on files that have not changed. The third is review, where the useful output is a side by side view of the changed lines, not a list.

Write the question down. It decides which of the steps below to run and which to skip. A backup check that relies on dates is not a verification, and a triage that hashes 400 GB of video is an afternoon lost for information that was available in seconds.

Two practical checks belong before any comparison. First, iCloud Drive: with Desktop and Documents in iCloud, a file can appear in Finder while its contents are still in the cloud, and a content check will start downloading it. Second, file counts. Run find /path/to/A -type f | wc -l and the same for B. If the counts are far apart, a folder was copied one level too deep or a transfer stopped early, and a detailed comparison will only bury that fact under thousands of lines.

A third check matters when one side came from Linux or a server. The default Mac volume format is case-insensitive, so README.md and Readme.md cannot both exist in one folder on the Mac. Copying such a pair onto the Mac with cp or rsync writes one over the other without asking, and a later comparison then reports a missing file that was never really missing on the source. If the counts differ by a handful, look for names that differ only in capitals before assuming anything was deleted.

Step one: the built-in diff command

diff ships with macOS. With two flags it compares whole folders:

diff -rq /path/to/A /path/to/B

-r walks into subfolders. -q reports only whether files differ, not how. The output has exactly two kinds of line:

Only in A: new.txt
Files A/f.txt and B/f.txt differ

On a test run for this article, an untouched folder pair produced one extra line that had nothing to do with the work: Only in A: .DS_Store. Finder writes that file into folders it has displayed, so it appears on one side and not the other almost every time. Exclude it:

diff -rq -x .DS_Store /path/to/A /path/to/B

To get the paths of files that exist on one side only, without opening any file at all, compare sorted name lists instead:

diff <(cd /path/to/A && find . -type f | sort) \
     <(cd /path/to/B && find . -type f | sort)

Lines starting with < exist only in A, lines starting with > only in B. This finishes in seconds on a tree of a hundred thousand files, because nothing is read except directory entries. It is the right first pass for photo libraries and video projects.

diff -rq is accurate about contents, since it reads files to decide. That also makes it slow on very large trees. For anything under a few gigabytes it is the simplest complete answer.

Step two: the rsync dry run, and the trap inside it

Many guides recommend a dry run of rsync to compare folders:

rsync -rtn --itemize-changes /path/to/A/ /path/to/B/

The -n flag means nothing is copied. The output lists what would be transferred. This is useful, but on current macOS it carries a limitation worth seeing for yourself.

First, the rsync on a current Mac is not the one most guides were written against. Running rsync --version on macOS today reports openrsync: protocol version 29 and rsync version 2.6.9 compatible. Its manual page describes the -c, --checksum flag as using full-file checksums instead of the default size and modification time "quick check".

The test, run on 8 October 2026:

1. Create A/f.txt containing hello world.
2. Create B/f.txt containing hellO world. Same length, one letter changed.
3. Copy A's modification time onto B's file with touch -r A/f.txt B/f.txt.
4. Run the dry run without -c. Output: nothing. The folders look identical.
5. Run it again with -c. Output: >fc...... f.txt. The difference appears.
6. Run diff -rq A B. Output: Files A/f.txt and B/f.txt differ.

So a default rsync dry run compares metadata, not contents. That is fine for triage. It is not a verification. Matching size and date happens more often than it sounds: restoring from a backup, copying with attributes preserved, unpacking an archive, and sync tools all set modification times on purpose.

For verification, add -c and accept that both sides are read in full:

rsync -rcn --itemize-changes /path/to/A/ /path/to/B/

The trailing slashes matter. A/ means the contents of A. A without the slash means the folder itself, which nests a copy one level down when the dry run is later repeated for real.

Step three: keep a record with checksum manifests

A comparison that scrolled off the screen proves nothing next month. For backups and handovers, write a manifest of hashes for each side and compare the manifests:

cd /path/to/A && find . -type f ! -name .DS_Store -exec shasum -a 256 {} + | sort -k2 > ~/a.sha256
cd /path/to/B && find . -type f ! -name .DS_Store -exec shasum -a 256 {} + | sort -k2 > ~/b.sha256
diff ~/a.sha256 ~/b.sha256

shasum is part of macOS. Each manifest is a plain text file with one line per file: the hash, then the relative path. Sorting by the path column puts both lists in the same order, so diff lines them up.

Three things make this worth the extra minute:

• The manifest of A can be compared against a third copy later, without A being connected.
• shasum -a 256 -c ~/a.sha256, run inside a copy, checks every file against the recorded hash and prints OK or FAILED per line.
• The text file can be sent to someone else as evidence that a delivery arrived complete.

On a large tree, run the name comparison from step one first. If whole folders are missing, hashing everything is wasted effort until that is fixed.

Step four: when a visual comparison app makes sense

Commands give exact lists. They do not let you click a difference, read both versions side by side, and copy one across. When the list is long and each item needs a judgement, a comparison app is faster. These were checked on their official pages on 8 October 2026.

Tool	What it is	Price as listed	Requirements
FileMerge	Apple's comparison app, included with Xcode, also opened by the opendiff command	Free with Xcode	Xcode installed
VisualDiffer	File and folder comparison, open source	Free	macOS 13 or later
DirEqual	Folder comparison app on the Mac App Store	Free download; $4.99 per month, $17.99 per year, or $49.99 lifetime; 7-day trial with the subscription	macOS 10.15 or later
Beyond Compare	File and folder comparison for Windows, macOS and Linux	Standard $35, Pro $70 per user, one-time, no annual renewal	Windows, macOS or Linux

UltraCompare, also on the first page of results, is sold for Windows, Mac and Linux, and its page states a personal license covers up to three machines.

How to choose among them:

• If Xcode is already installed, try FileMerge first. In Terminal, opendiff /path/to/A /path/to/B opens both folders in it.
• If nothing should be installed beyond a small app, VisualDiffer costs nothing.
• If the same comparison is repeated often across drives, DirEqual and Beyond Compare are built around folder trees, filters and repeat sessions.

None of these change what step two showed. Check each app's settings for whether it compares by contents or by size and date, and switch to contents when the answer has to be certain.

Step five: act on the result without overwriting the wrong side

The comparison itself is harmless. The copy that follows is where work gets lost.

Decide the direction in words before typing: which folder is the source of truth for this job. Then decide what happens to files that exist only in the destination. rsync --delete removes them. Without that flag they are kept. Both are reasonable, and the wrong one on the wrong side is the most common way a sync destroys something.

A safe routine:

1. Run the command with -n and read the output.
2. Remove only the n. Change nothing else.
3. Run it again.

The dry run and the real run should differ by one character, so the command that executed is the command that was inspected.

When both folders contain new work, there is no safe single command. Sort the differences first. Files present on one side only are usually a simple keep or discard decision. Files that differ in content are the ones to open. If that second group is small, resolve each by hand. If it is large, keep one folder as an archive under a dated name and carry on in the other, rather than forcing a merge.

Step six: when comparing folders is a weekly job

A one-time comparison is a task. Doing it every week turns into a loop across three places: a folder view to see the files, a terminal to run diff or rsync, and often an AI assistant to write the command. The result lives as text in the terminal, and turning a list of paths back into files to open means finding each one by hand in Finder.

What shortens that loop is fewer windows, not a cleverer command. A file manager with a built-in terminal keeps the terminal attached to the folder on screen, so a command runs where the files already are. That approach is one of several; the comparison with other file managers lays out the trade-offs, and the feature list shows what is included.

What to change first

Run diff -rq -x .DS_Store for small folders and a sorted name comparison for large ones. Never use a plain rsync -n as proof of a match on current macOS; add -c, or keep shasum manifests when the answer has to be shown to someone later. If the comparison is one step in a daily loop of looking, running and fixing, Atriens puts the folders and the terminal in one window, free on the Mac.