A copy tool can tell you a file transfer "completed" without knowing anything about whether the destination file is actually correct. Checksum verification is how you close that gap — and it's simpler than it sounds.
The short version: a checksum is a fingerprint of a file. A verified copy hashes the source and the destination with SHA-256 and compares the two: if they match, the copy is identical down to the bit. A good tool hashes the source while copying, so the card is read only once.
What a checksum actually is
A checksum (technically a cryptographic hash) is a function that takes a file of any size and produces a short, fixed-length fingerprint — for SHA-256, a string of 64 hexadecimal characters. Two properties make it useful here: the same input always produces the exact same fingerprint, and changing even a single bit of the file produces a completely different one. There's no "almost the same" checksum — a file is either identical to the one that produced a given hash, or it isn't.
How verified copying actually works
If the two hashes match, the destination file is, for all practical purposes, identical to the source — down to the bit. If they don't match, something changed during the transfer: a dropped byte, a flaky cable, a card reader that hiccupped halfway through. Either way, you know before you've moved on and reformatted the card, not weeks later when the file won't open.
MD5 vs SHA-256
Older tools often used MD5, which is fast and was good enough for a long time — but MD5 has known weaknesses that let two different files be deliberately crafted to produce the same hash (a "collision"). That's a real problem for security uses like verifying software downloads; for accidental corruption on a memory card, a deliberate collision isn't the threat model. Even so, SHA-256 has become the practical standard in modern delivery pipelines and broadcast specs (it's one of the algorithms supported by the ASC MHL standard), and it costs very little extra time to compute — so there's not much reason to default to the weaker option anymore.
The efficiency trap: don't read the card twice
The naive way to verify is to copy the file, then go back and re-read the source to hash it, then read the destination to hash that too — three full reads for one file. On a 128GB card that adds real minutes. The better approach computes the source hash while streaming the copy, so verification effectively costs one extra read (the destination check) instead of two.
How ShotGrab does it: every file is copied with SHA-256 computed live during the single read of the source — never a separate pass just to hash it — then confirmed against the destination before the file is promoted out of its temporary holding location. Verification isn't a setting to turn on; it runs on every file, every time. Files imported before ShotGrab moved to SHA-256 still carry their original MD5 checksum, clearly labeled as MD5 rather than silently treated as something stronger than it is.
Frequently asked questions
What is checksum verification?
A hash function such as SHA-256 turns a file into a short, fixed-length fingerprint. The tool hashes the source and the copy and compares them: a match means the copy is identical to the original down to the bit.
Is SHA-256 better than MD5 for verifying file copies?
MD5 has known weaknesses that allow deliberate collisions. For accidental corruption that isn't the main threat, but SHA-256 is now the practical standard (it's supported by ASC MHL) and costs very little extra time, so there's little reason to default to MD5.
Does checksum verification slow down copying?
Not much if it's done right. Hashing the source while the copy streams avoids reading the card a second time, so verification costs roughly one extra read of the destination.
What does a checksum mismatch mean?
Something changed during the transfer, such as a dropped byte, a flaky cable or a card reader that hiccupped. You find out before you reformat the card, not weeks later when the file won't open.