An MHL (Media Hash List) is a machine-readable manifest that pairs every file in a folder with its cryptographic checksum - and turns "I copied it" into "here is mathematical proof the copy is identical." The official site describes it as "an XML format, that basically lists all the files in a folder and all of its subfolders as well as the corresponding checksums." One piece of attribution folklore is worth correcting: MHL was created by Pomfort (whose site mediahashlist.org is), and its second version was standardized as ASC MHL by the American Society of Cinematographers' Advanced Data Management Subcommittee - not by an NLE vendor. Here is what lives inside one, the loop it powers, and the boundary with review links.
What is inside an MHL file
Each entry pairs a path with one or more hash values - digests computed from the file's bytes. The format family supports the industry's working algorithms: the official site names SHA-1, MD5, and xxHash, and the ASC MHL specification enumerates the supported hash formats as md5, sha1, xxh64, xxh3, xxh128, and c4id. The algorithms trade speed against rigor: xxHash variants are extremely fast (the reason on-set offloads favor them), while SHA-1/MD5 are the long-standing digests delivery specs often name. The manifest records the verification, not just the intention - the official site lists what a hash history catches: "Empty files," "Changed files," "Removal or missing of files."
The chain of custody
The ASC MHL specification's own framing is the best one-line definition of the workflow's purpose: "create a chain of custody by tracking each and every copy made between the media's initial download on set, all the way through to final archive." Each verified copy appends to the history, so at any point you can answer the question a damaged shoot day eventually asks: was this file intact when it left the card, when it reached the RAID, when it reached the archive? Pomfort's Silverstack and Offload Manager tooling documents the loop directly - creating, verifying, and continuing ASC MHL checksum histories across offloads (their walkthrough here), which is the practical implementation of the data-management role described in the DIT explainer.
Delivery checksums
The same discipline governs hand-carried deliverables. The DCP world's documentation is the clearest example: easyDCP's FAQ instructs producers to "run a Hash-check (e.g. with MD5) of the DCP before copying to the hard disc. After copying run the Hash-check again", and states flatly that "the results of the hash-check must be identical otherwise the DCP may crash" - with the drive formatted EXT2/EXT3 per cinema-server convention. The generalized rule for any drive delivery (masters to a broadcaster, archives to a facility): generate checksums before the drive leaves, verify on arrival, and travel the manifest with the media. It pairs with the packaging discipline in the delivery checklist and the naming discipline in file naming conventions.
MHL vs a plain checksum sidecar
A lone MD5 text file (one hash per line) verifies a single copy step. An MHL/ASC MHL accumulates a history - multiple hash generations per file, signed entries, the trail of who verified what and when - which is why productions standardized on it rather than loose sidecars. When a delivery spec says "include checksums," an ASC MHL satisfies it and documents its own provenance; when a spec names MD5 values specifically, plain sidecars remain the interop answer.
The review-link boundary
Do review uploads need checksums? No - and this is a boundary worth understanding rather than a feature to wish for. Platform transfers run over resumable, integrity-checked connections; the transport layer already detects corruption (how large-file sharing works covers that mechanics). Checksum manifests answer a different question - proving file identity across independent storage hops where no shared transport exists: card to RAID, RAID to archive, machine to hand-carried drive. Review links are approval surfaces; MHLs are evidence surfaces. Productions that need both use both - the graded master gets a checksum manifest when it drives to the broadcaster, and the review round that approved it lives on the link.
FAQ
Should I use MD5 or xxHash for offloads?
xxHash (xxh64/xxh3) for speed on set - it verifies faster than it reads on modern hardware, which is why offload tools favor it; MD5/SHA-1 when a delivery spec names them explicitly. ASC MHL supports both families, so the history can carry whichever the moment needed.
Do I need an MHL for a client delivery drive?
If the delivery spec asks for checksums, yes - generate hashes before the drive leaves and travel the manifest with it. The DCP convention is the documented exemplar: hash before copying, hash after, results must match.
What software creates MHL files?
The offload/verify class of tools - Pomfort's Silverstack and Offload Manager implement create-verify-continue ASC MHL workflows, and the open-source tooling around the ASC MHL spec handles generation and verification. NLEs generally do not create them; data-management tools do.
Is an MHL the same as a checksum file?
A plain checksum sidecar verifies one copy step; an MHL records a history - entries per file per generation, accumulating across every verified copy from card to archive. The history is the difference, and it is why the ASC standardized v2 rather than settling for loose MD5 text files.
Do uploads to a review platform need checksum verification?
No - resumable, integrity-checked transfers already detect corruption in transit, which is what review uploads are. MHLs matter for storage-to-storage hops with no shared transport: card to RAID, RAID to archive, hand-carried drives. Different question, different tool.