xxHash vs MD5: the fastest checksum for video

Written by a working DIT · Copsy · Last verified June 2026

Short answer

For verifying footage on set, xxHash wins. It catches a bad copy, a dropped byte or a corrupt card just as reliably as MD5 or SHA, and it runs many times faster. That means verification doesn't bottleneck your offload. MD5 and SHA are cryptographic hashes built to resist deliberate tampering, which a camera card never does. That security costs speed you don't need when copying your own media.

That's why xxHash is the popular checksum on set, and why Copsy, a free Mac camera-offload app, verifies every file it copies with ASC-MHL checksums, for free, with no signup.

Download Copsy for Mac → · macOS 13+ · no account needed

What a checksum actually does

A checksum (or hash) reads every byte of a file and boils it down to a short fingerprint. Copy the file, hash the copy, and compare: if the two fingerprints match, the copy is bit-for-bit identical to the source. If even a single byte changed — a flaky cable, a dying card, a write that didn't finish — the fingerprints won't match, and you know before you wipe the card. That is the whole point of a verified offload: proof, not hope.

The job is the same for every algorithm. What differs is the trade-off between how fast it produces that fingerprint and what it was designed to defend against.

Two different jobs: speed vs. security

This is the part most people get backwards. There are two families of hash, and they were built for two different problems:

Cryptographic hashes (MD5, SHA-1, SHA-256): designed so that nobody can deliberately craft two different files with the same hash. That matters for passwords, signatures and downloads from the internet. It is irrelevant when you copy your own camera card — nobody is attacking your footage. The security work makes them slower.
Non-cryptographic checksums (xxHash, CRC): designed purely to detect accidental change as fast as possible. xxHash can run close to memory speed, so it verifies huge media files without becoming the slow part of a copy.

The honest truth about MD5 being "broken"

You'll read that "MD5 is broken." That's true only for security — someone intentionally engineering a collision. For detecting whether your file copied correctly, MD5 is still perfectly reliable. Its real problem on set is speed, not safety: it's much slower than xxHash on multi-gigabyte clips, and a shoot day is many gigabytes.

xxHash vs MD5 vs SHA — comparison

Property	xxHash (xxHash64 / XXH3)	MD5	SHA-1 / SHA-256
Built for	Speed — catching accidental corruption	Cryptographic security (now broken)	Cryptographic security
Relative speed on large video	Fastest (often several GB/s)	Slow	Slowest (esp. SHA-256)
Catches a bad / corrupt copy	✓ reliably	✓ reliably	✓ reliably
Resists deliberate tampering	No (not its job)	No (broken)	SHA-256 ✓
Slows down your offload?	Barely	Noticeably	Most
Common on film sets / DIT tools	✓ default in many tools	legacy / on request	rarely for offload
Supported by ASC-MHL	✓	✓	✓

Speed depends heavily on your CPU, disk and cable — treat the ranking as relative, not absolute numbers. Last verified June 2026.

Why xxHash is popular on set

A DIT's whole job is to get cards offloaded and verified fast enough to keep up with the shoot. Footage is enormous — a single CFexpress card can be hundreds of gigabytes, and a day can run into terabytes. Every checksum has to read every byte, so a slow hash directly slows the copy.

xxHash solves that: it verifies the same data many times faster than MD5 or SHA while still catching any difference between source and copy. That's why it shows up as the default in pro workflows. DaVinci Resolve's free Clone Tool, for example, uses xxHash64 to verify card copies. When verification is nearly free, there's no excuse to skip it, and "I verified the card" stops being a luxury.

How ASC-MHL ties it together

Picking xxHash is only half the story. The other half is recording proof that travels with the footage. That's what ASC-MHL (the American Society of Cinematographers Media Hash List) does: it writes a manifest listing every file, the hash of each one, and which algorithm was used (xxHash64, MD5, SHA-1 and more are all supported). Hand the drive to post, and anyone downstream can re-verify the exact bytes you shot.

So the modern best practice is simple: verify with a fast hash like xxHash, and record it in an ASC-MHL manifest. Speed where you need it, proof you can hand off.

How Copsy verifies every copy

Plug in the card. Copsy detects it by content and recognizes the camera/source (Sony, ARRI, Blackmagic/BRAW, RED, Canon, drones, audio — or any volume).
Pick destinations. An external drive, plus optionally Google Drive or Dropbox — copied in parallel.
Copy + verify. Copsy hashes every file and checks the copy against the source using ASC-MHL checksums, then organizes by date and source.
Get pinged. A Telegram message tells you it finished and verified — nothing lost, nothing to babysit.

You get the thing that matters most, a real, checksum-verified offload, without paying for it and without thinking about which algorithm to choose.

Frequently asked questions

Is xxHash better than MD5 for verifying video?

For verifying a file copy on set, yes — xxHash is the better choice for most people because it is far faster than MD5 and just as good at catching accidental corruption, dropped bytes or a bad copy. MD5 and SHA are cryptographic hashes built to resist deliberate tampering, which a camera card does not do. xxHash is a non-cryptographic checksum built purely for speed, so it keeps verification from slowing down your offload.

Why do DITs use xxHash instead of MD5?

Because footage files are huge and a shoot day can be terabytes. A cryptographic hash like MD5 or SHA reads every byte through a slow algorithm, which can bottleneck a copy. xxHash verifies the same data many times faster while still detecting any difference between the source and the copy, so DITs get a verified offload without waiting. xxHash64 is also the default verification in tools like DaVinci Resolve's Clone Tool.

Is MD5 still safe to use for checksums?

For verifying that a file copied correctly, yes — MD5 will reliably catch accidental corruption. MD5 is considered broken only for cryptographic security (someone deliberately crafting two different files with the same hash), which is not a threat when you are copying your own camera card. The real downside of MD5 for offload is simply speed: it is much slower than xxHash on large media files.

What checksum does ASC-MHL use?

ASC-MHL (the American Society of Cinematographers Media Hash List) supports several hash types, including xxHash64, MD5, SHA-1 and others, and records the choice inside the .mhl manifest. That means a verified offload travels with proof of which algorithm was used and the hash of every file, so anyone downstream can re-verify it. You can read more on our What is ASC-MHL guide.

Which checksum should I use when I offload a camera card?

Use a fast, modern checksum like xxHash for day-to-day card offloads — it verifies every file without slowing the copy. Use MD5 or SHA only if a specific delivery spec or post house asks for it. The most important thing is that you verify at all: a copy that is not checksum-verified can silently lose or corrupt a file. Copsy verifies every file it copies using ASC-MHL checksums, for free.

Verify every card for free

Copsy — a free Mac camera-offload app. Fast, ASC-MHL-verified copies to a drive and the cloud, nothing lost.

⬇ Download Copsy for Mac

macOS 13+ · No card, no signup, no limits