How to know if your footage copied correctly on a Mac
"It finished copying" and "it copied correctly" are two different things. A Finder drag can silently drop or corrupt a file while the window still says done. The only real proof is a checksum: hash every file on the card, hash every copy, and compare. If the fingerprints match, the file landed bit-for-bit.
Copsy does this for you automatically. It hashes each file as it reads the card, copies it to your drive (and optionally Google Drive or Dropbox), re-hashes the copy, compares, and records every hash in an ASC-MHL file. Then it pings you on Telegram when the card is done and verified. Free, no signup.
Download Copsy for Mac → · macOS 13+ · no account needed
The dangerous part: a copy can look done and still be broken
When you drag a card's contents into a folder, Finder shows a progress bar and then stops. The bar reaching the end only means Finder believes it wrote the expected number of bytes. It does not mean those bytes are correct, or that every file even made it across. Cards, cables, card readers, RAM and drives all fail in quiet ways: a read error here, a flipped bit there, a file that gets skipped when a reader hiccups mid-transfer. None of that throws an obvious alert.
The result is the worst kind of problem on a shoot. A clip is there, has the right name and roughly the right size, then corrupts somewhere in the middle, discovered days later in the edit, long after the card was reused. The card is your only original. If the copy is silently bad and the card is wiped, the footage is gone.
Why file size alone doesn't prove anything
The most common "verification" people do is glance at the file size or the folder size and call it a match. Size matters, but it is nowhere near enough. It only counts how many bytes are present, not whether those bytes are the right bytes.
A drive can write exactly the correct number of bytes and still scramble some of their values. A flaky USB cable, a failing CFexpress card, bad memory, or a silent read error can flip bytes inside the file while the total length stays identical. The copy reports the same size, opens fine, maybe plays for two seconds, then glitches or crashes. Size will never catch that. Only something computed from the actual byte values will, and that's a checksum.
What a checksum actually is
A checksum is a hash, a short fixed-length fingerprint calculated by running a hash function over every byte in a file. Change a single bit anywhere in the file and the fingerprint changes completely. So the test is simple and absolute:
- Hash the file on the card → you get fingerprint A.
- Hash the copied file on your drive → you get fingerprint B.
- If A equals B, the copy is bit-for-bit identical. If they differ, even by one byte, you know the copy is bad before you trust it.
This is the method professional offload tools and Netflix-style delivery workflows rely on. The common hash choices are xxHash (very fast, ideal for huge video files), MD5 and the SHA family. For verifying a copy is intact, speed matters more than cryptographic strength, which is why xxHash is popular for footage.
Where ASC-MHL comes in
Computing hashes is only useful if you keep them. ASC-MHL (the American Society of Cinematographers' Media Hash List) is a standardized file that records the hash of every file in an offload, when it was copied, and with which algorithm. It travels alongside the footage as a permanent, portable record of what was copied and that it verified.
That record is what lets anyone down the line, an editor, a post house, an insurer, re-verify the footage later and prove it never changed. A folder of clips with no MHL is just a folder of clips. The same folder with a matching MHL is documented, verified media.
How to verify a copy yourself, step by step
If you want to confirm a copy by hand, run these three checks in order. Each one catches a failure the previous one misses.
- Count the files. Compare the number of files on the source card against the number in the copy. A mismatch means a file was skipped or dropped, so stop and recopy. (Don't forget hidden sidecar and metadata files; cameras write more than just the obvious clips.)
- Compare the byte counts. Check that the total byte count, and ideally each file's byte count, matches between source and copy. This catches truncated or partially-written files. It does not catch flipped bytes, which is why it's not the last step.
- Compare the checksums. Hash every source file and every copied file and compare them one-to-one. Matching hashes are the only proof the bytes are actually identical. On a Mac you can do this from Terminal (for example
shasumor anxxhsumtool), but doing it correctly for an entire card (every file, both sides, recorded) is tedious and easy to get wrong.
Copsy does all three automatically
- Counts and matches every file on the card against the copy, including the sidecars people forget.
- Checks byte counts so a truncated file never slips through.
- Hashes each source file, copies it, re-hashes the copy and compares bit-for-bit, then writes every hash into an ASC-MHL file next to the footage.
- Copies to your external drive and optionally Google Drive or Dropbox in parallel, organizes by date and source, and pings you on Telegram when the card is done and verified.
No separate verify step to remember, no box to tick. Every offload in Copsy is verified. Free, no card limit, no signup.
The honest limits
Copsy is macOS-only (macOS 13 or later). There's no Windows build. It also doesn't do LTO/LTFS archiving or plug into Premiere/Resolve panels. It's focused on one thing done right: detecting your card, copying it to a drive and the cloud, and verifying every file with ASC-MHL checksums. If your pipeline needs Windows or a full studio toolchain, you'll want a paid suite. If you mainly need proof your footage copied correctly, that's exactly what Copsy gives you for free.
Frequently asked questions
Offload your next card for free
Copsy, a free Mac camera-offload app. Verified copies to a drive and the cloud, nothing lost.
⬇ Download Copsy for Mac