Before you format the card
Short answer: a finished progress bar is not proof, and neither is a matching file count or a matching folder size. The only thing that proves a copy is a copy is comparing the contents of the files.
You can do that for free, today, with a tool already built into Windows. No download and no purchase. The walkthrough is further down this page, and it works whether or not you ever use anything of ours.
Formatting a card is irreversible in a way almost nothing else in this workflow is. Ten minutes of checking is cheap against that.
Most copies succeed. That's exactly what makes the failures dangerous — you stop expecting them, and the ones that do happen tend to be quiet.
Here is what actually goes wrong, in rough order of how often photographers hit it:
This is the big one, and it has nothing to do with faulty hardware. Cameras number files sequentially and reset those counters. Two bodies at the same event will both happily produce DSC_0001, IMG_0047, GX010023. Copy both cards into one folder and Windows asks whether to replace, skip, or keep both. Click the wrong button once, at the end of a fourteen-hour day, and you have silently overwritten one camera's frames with another's. The copy reports success because, from the operating system's point of view, it was a success.
A reader that loses contact, a laptop that sleeps, a cable nudged with a knee. Depending on where it stopped, you can be left with a file that has the right name and a partial body. It appears in the folder listing. It opens as a thumbnail. It is not the whole photograph.
Windows sometimes reports skipped items in a collapsed summary you have to expand. A permissions issue, a filename length problem, a locked file, a subfolder that wasn't included in the drag. The dialog closes and the count of what didn't make it goes with it.
Flash memory wears out. A card near end of life can return read errors on specific files while the rest of it behaves perfectly. Some copy tools stop, some skip, some copy whatever they got.
None of these are common. All of them are silent. And formatting is the one action in this workflow with no undo.
Counting files on the card and counting files in the archive folder feels like verification. It is a useful smoke test and nothing more.
The filename collision case defeats it directly: if two cameras produced twelve colliding names and you chose "replace" for all of them, your archive is short twelve photographs — but it is also short twelve files, so the count simply looks different and you may well assume you miscounted a card.
Worse, counts can match while contents don't. Cameras write companion files: .THM thumbnails, .LRV low-resolution proxies, .XMP sidecars, GoPro's separate .WAV audio. Between a card and an organised event folder, those get added, dropped and reorganised constantly. Two numbers landing on the same total tells you the totals match. It tells you nothing about which files.
Comparing folder sizes is a better smoke test than counting, because a truncated file usually does change the total. But it still isn't proof, for two reasons.
First, Windows reports two different numbers — "Size" and "Size on disk" — and the second depends on the cluster size of the filesystem, which differs between a card formatted exFAT and an archive drive formatted NTFS. The same files will legitimately report different totals on the two volumes. People see the mismatch, decide it's a formatting artefact, and stop looking. Sometimes they're right.
Second, and more importantly: size is an aggregate. It can only ever tell you that something, somewhere, is different. It cannot tell you which file, and it cannot rule out the case where one file grew and another shrank.
Of the three, this is the one that actively causes damage rather than merely failing to prevent it.
We know because we built it that way first. The earliest version of what became DuplicateFinder Pro matched files by name. Run against one real event folder, that approach produced 349 false positives — files it confidently called duplicates that were nothing of the kind, just similarly numbered frames from different moments of a ceremony. Acting on that output would have meant deleting irreplaceable footage of a baptism because two cameras happened to share a naming convention.
The failure runs in both directions. Identical names on non-identical files, and identical files under different names — the same photograph exported twice, or copied into an organised folder and renamed on the way in. A name is a label a human or a camera attached to a file. It carries no information about what is inside.
Filenames lie. Content doesn't.
The only verification that means anything is reading both files and confirming they are byte-for-byte identical. In practice you don't compare the files directly — you compute a hash of each one.
A hash function reads every byte of a file and produces a short fixed-length fingerprint. Change a single bit anywhere and the fingerprint changes completely. Two files with the same SHA-256 hash are, for every practical purpose, the same file — regardless of what they're named, where they live, or when they were written.
So the question "did every photo on this card make it into my archive?" becomes a question you can actually answer: is every hash from the card present somewhere in the archive?
Windows has had this built in since PowerShell 4. You don't need to install anything, and you don't need our software.
Open PowerShell (press Start, type powershell, press Enter) and paste the following, changing the two paths to your card and your archive folder:
$card = Get-ChildItem -Path 'E:\DCIM' -Recurse -File | Get-FileHash
$archive = Get-ChildItem -Path 'D:\Events\Smith Wedding' -Recurse -File | Get-FileHash
$archiveHashes = $archive.Hash
$missing = $card | Where-Object { $archiveHashes -notcontains $_.Hash }
"Files on card: " + $card.Count
"Not found in archive: " + $missing.Count
$missing | Select-Object PathIf the second number is 0, every single file on that card exists somewhere inside your archive folder, verified by content. Names don't matter. Folder structure doesn't matter. You are safe to format.
If it isn't zero, the last line prints exactly which files are missing, and you can go look at them before doing anything irreversible.
Checking after the fact is the right move when the copy already happened. For future card dumps, a copy tool that verifies as it writes removes the question entirely. TeraCopy is free for personal use and does exactly this. It is not our software and we get nothing if you use it.
The PowerShell approach above genuinely answers the question on this page. It stops being practical in three situations, and it's worth being clear about which.
That second column is the gap. Hashing every file on two multi-terabyte drives is enormously wasteful, because most files can be ruled out without reading them at all — anything with a unique size cannot possibly have a match.
It runs the same content comparison, in three stages, cheapest first.
That ladder is why a multi-terabyte comparison finishes at all. Scans checkpoint at phase boundaries, so an interrupted run resumes instead of restarting. And nothing is deleted: flagged files move to a quarantine folder on the same drive with a 24-hour hold and one-click restore to their exact original path.
Scanning and the full reports are free and require no account. You can point it at a card and an event folder, get the same answer this page describes, and never pay anything. A licence is only needed to move files into quarantine.
Windows 10 and 11. RAF, CR3, CR2, NEF, ARW, DNG, JPG, MOV, MP4 and GoPro WAV.
Formatting in the camera is generally the better habit, because it writes the folder structure the camera expects. But that's a separate question from whether your photos are safe. Verify first, then format wherever you prefer.
Two copies is meaningfully safer than one, and it protects you against a drive failing later. It does not protect you against a copy that was incomplete in the same way twice, which is exactly what happens with a filename collision or a card that is failing to read a particular file.
SHA-256 is the default for Windows' built-in command, so the example uses it without needing an extra argument. MD5 is faster and is the right trade for scanning terabytes, where the concern is accidental corruption rather than someone deliberately constructing a collision.
Yes. The method is identical — the two paths are just folders, and either one can be a drive root. Be aware that hashing an entire drive with the PowerShell approach reads every byte of it, which is where a staged comparison becomes worth having.
Stop writing to the card immediately and look into photo recovery software. Deleted data usually remains on the card until it is overwritten, so the sooner you stop using it, the better your odds. That is a different kind of tool than this one, and we don't make it.