How to verify a file copy on Mac

By Ting Tze Chuen · Updated October 7, 2026

Finder doesn't verify copies. To confirm a copy matches the original, compare checksums of both: run shasum -a 256 on each file in Terminal, compare whole folders with diff -rq, or build a checksum list with shasum -c. An app like VerifiedCopy does the same thing automatically, re-reading every copy and comparing SHA-256 hashes.

Does Finder verify copied files?

No. When you drag files to another drive, Finder reports the copy as finished once the last write has been handed to the drive. It never reads the copied file back to check that the bytes on the destination match the source. If a cable drops out for a moment, a card reader stalls, or a sector on the destination is failing, the copy can be damaged and Finder will still show it as complete.

Most of the time copies are fine. The problem is that you can't tell which times they aren't until you open the file, which might be months later, after the original is gone.

What "verifying a copy" actually means

Verifying means reading the copy back from the destination drive and comparing it with the original. The usual way is a checksum (also called a hash): a short fingerprint calculated from every byte of a file. If even one bit differs, the checksum changes completely. SHA-256 is the standard choice today; MD5 also catches accidental corruption but is considered obsolete for security uses.

Tip: right after a copy, macOS may still hold the file in memory. For a manual check, eject the destination drive and plug it back in first so the verification reads from the drive itself.

Method 1: Compare one file with shasum

macOS includes shasum. Open Terminal and run it on both files:

shasum -a 256 ~/Movies/birthday.mov /Volumes/Backup/birthday.mov

You'll get two lines, each starting with a 64-character hash. If the hashes are identical, the files are identical. For a quick yes/no without hashes, cmp file1 file2 prints nothing when the files match.

Method 2: Compare two folders with diff

To check a whole folder, such as a camera card against its backup:

diff -rq /Volumes/CARD/DCIM /Volumes/Backup/DCIM

diff compares the contents of every file, byte for byte. No output means every file matches. Otherwise it lists files that differ or exist on only one side. It's thorough, but it leaves no record you can check again later.

Method 3: Make a checksum list and check against it

This is the most useful manual method because the list doubles as a record. First, hash every file in the source folder:

cd /Volumes/CARD
find . -type f ! -name '.DS_Store' ! -name '._*' -print0 | sort -z \
  | xargs -0 shasum -a 256 > ~/card.sha256

Then check the copy against that list:

cd /Volumes/Backup/CARD
shasum -a 256 -c ~/card.sha256

Each file is reported as OK or FAILED. Keep the .sha256 file next to the backup and you can re-run the check in a year to catch corruption that crept in later. The find filters skip Finder's .DS_Store and ._ metadata files, which often differ between drives without meaning anything is wrong.

Method 4: rsync dry run with checksums

rsync -rcnv /Volumes/CARD/ /Volumes/Backup/CARD/

-c compares checksums instead of size and date, and -n makes it a dry run, so nothing is copied. Any file it lists is one rsync would re-send, meaning it differs or is missing. You have to remember to run it, and it can't tell you which part of a large file is damaged.

Method 5: Use an app that verifies every copy

VerifiedCopy builds the check into the copy. It copies your files to up to three drives in chunks of 1 to 16 MB. Each chunk is written, flushed to the drive, read back, and its SHA-256 hash compared with the source; a chunk that doesn't match is rewritten and checked again. A full-file SHA-256 pass follows by default. Each job can save a CSV or JSON report to the destination, and to re-check a backup later, Verify & Repair scans it against the original and rewrites only the damaged chunks.

Which method should you use?

Method	Checks contents	Whole folders	Reusable record	Repairs
Finder copy	No	n/a	No	No
`shasum` / `cmp`	Yes	One file at a time	No	No
`diff -rq`	Yes	Yes	No	No
`shasum -c` list	Yes	Yes	Yes	No
`rsync -rcn`	Yes	Yes	No	Re-copies whole files
VerifiedCopy	Yes, automatically	Yes, up to 3 destinations	Yes, CSV or JSON report	Only damaged chunks

For an occasional single file, shasum is enough. If you regularly copy photo libraries, footage, or archives, verification works best when it happens on every copy without you having to remember it.

Frequently asked questions

Does copying files in Finder check for errors?

Finder reports errors the drive itself reports, such as a disconnected drive or a full disk. It doesn't read the copy back, so silent corruption, where the drive accepts the data but stores it wrongly, goes unnoticed.

Is MD5 good enough to verify a file copy?

For catching accidental corruption, MD5 works. SHA-256 is the modern default and avoids MD5's known weaknesses, so use it when you have a choice. On Mac, shasum -a 256 and md5 are both built in.

How long does verifying a copy take?

Verification reads every byte of the copy again, so it takes roughly as long as reading the data once more from the slower of the two drives. On a fast SSD that's a small addition to the copy; on a USB 2.0 card reader it's noticeable.

Can I verify files I copied a long time ago?

Yes, as long as you still have the originals or a checksum list made from them. Use diff -rq against the originals, or shasum -a 256 -c against a saved list. VerifiedCopy's Verify & Repair can also scan an old backup against a known-good source and fix only the damaged parts.

Why do my checksums differ when the files look identical?

If the file sizes match but the hashes differ, the contents are different, even if the file still opens. Damaged video often plays until it reaches the bad section. Copy the file again from the original and check it again.