Introduction
Your DIT station just finished a 4-hour offload of a RED V-RAPTOR 8K shooting day onto two G-RAID drives. The second copy finishes and you need to confirm every file on drive B is a byte-for-byte match with drive A before you hand anything to the director and call wrap. ShotPut Pro generated an MHL manifest. The producer asks: "How do we actually know this worked?" That is the moment every DIT needs a reliable, private checksum tool.
The File Checksum Verifier runs MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hashes entirely inside your browser using WebAssembly. No file is uploaded anywhere. No network request leaves your machine. You can verify an unreleased feature film's dailies without a single frame hitting a third-party server. Drop a file, paste the expected hash from your MHL manifest or ShotPut report, and get an instant verified or mismatch result.
What This Tool Calculates
The tool accepts any number of files dropped or selected via the file browser. For each file it computes 5 hash digests in a single streaming pass: MD5 (32 hex characters), SHA-1 (40 hex characters), SHA-256 (64 hex characters), SHA-384 (96 hex characters), and SHA-512 (128 hex characters).
Inputs are the raw file bytes, read in 64 MB chunks via the File.slice() API. The only other input is the optional expected hash field: paste any hash string and the tool auto-detects which algorithm generated it by character count. It then highlights the matching algorithm row green (verified) or red (mismatch) for every file in your queue.
Outputs are the computed hex digests displayed in monospace with one-click copy buttons, a live progress bar per file showing bytes processed, and exportable results as a .csv or .json file for archiving alongside your camera reports.
The Formula and How It Works
All five algorithms produce a fixed-length digest from a variable-length input. The underlying math is defined in the following standards:
**MD5** (RFC 1321, Rivest 1992): A 128-bit (32 hex char) digest using a 4-round Merkle-Damgard construction with 32-bit word operations. Cryptographically broken for collision resistance since 2004, but preimage-resistant for practical file sizes. RFC 6151 confirms MD5 remains acceptable for "protection against errors" (accidental corruption), which is its only use case in modern post-production.
**SHA-1** (FIPS PUB 180-4, NIST): A 160-bit (40 hex char) digest. Theoretically broken for collision resistance since 2017 (SHAttered attack, Stevens et al.) but still used in legacy MHL manifests and some DIT tools. Avoid for security-sensitive verification; use for MHL compatibility only.
**SHA-256** (FIPS PUB 180-4, NIST): A 256-bit (64 hex char) digest. Part of the SHA-2 family. Current industry standard for digital delivery verification, DCP package integrity, and ASC MHL v2 manifests. Throughput on hash-wasm (WebAssembly): approximately 426 MB/s, meaning a 100 GB RED camera card takes roughly 3.9 minutes to hash.
**SHA-384 and SHA-512** (FIPS PUB 180-4, NIST): 384-bit and 512-bit digests using a 64-bit internal word size. Faster than SHA-256 on 64-bit CPUs for large files. Use SHA-512 when an archival facility or streaming platform delivery spec requires it.
**Streaming implementation**: Because cinema files can exceed 50 GB and the browser cannot load that into memory at once, this tool reads files in 64 MB chunks using File.slice(start, end), feeds each chunk into an incremental hash-wasm hasher, and yields to the event loop between chunks so the progress bar updates and the UI remains responsive. All 5 hashers process each chunk in the same pass so the file is only read once.
Worked example: A BRAW 8:1 clip from a Blackmagic URSA Cine 12K measures 23,847,552,000 bytes (approximately 22.2 GB). At 426 MB/s throughput, SHA-256 completes in approximately 52 seconds. The tool reads 372 chunks of 64 MB plus one final 23.4 MB chunk. The resulting SHA-256 is a 64-character hex string the DIT pastes directly into a delivery manifest. The producer's facility hashes the same file on arrival and compares strings. A match means no corruption in transit; any single flipped bit produces a completely different digest.
Real-World Examples
Example 1: DIT On-Set Offload Verification (Sony VENICE 2, 30-Day Feature)
On a 30-day union feature, the DIT offloads 3 camera cards each day to 3 drives: on-set master, on-set clone, and producer's off-site backup. Total daily volume averages 1.2 TB across 340 files. ShotPut Pro generates an MD5 MHL manifest for each card.
At the end of each offload, the DIT drops all 340 files from the on-set clone drive into the File Checksum Verifier in one batch. He pastes the expected MD5 from the MHL manifest row by row into the expected hash field. Because MD5 is 32 characters, the tool auto-detects the algorithm on each paste. All 340 files return green verified badges. Total verification time per day: approximately 18 minutes running SHA-256 alongside MD5 simultaneously for a stronger double-check.
On day 22, one file returns a red mismatch badge. The SHA-256 of the clone does not match the on-set master. The DIT identifies the source as a defective SanDisk Extreme Pro card that had written a corrupted cluster. Because the third drive (off-site backup, offloaded directly from the same card) had the same corruption, the master drive becomes the only valid copy. The mismatch catch saves a day of reshoots estimated at $180,000 in crew and equipment costs.
Example 2: Documentary Post-Production File Delivery Verification
A documentary post house delivers a 47-minute UHD master to a broadcaster in an IMF package. The delivery spec requires SHA-256 checksums for every MXF essence file and XML composition map. The package contains 18 files totaling 312 GB.
The post supervisor drops all 18 files into the File Checksum Verifier. The tool hashes all files sequentially. Total time: approximately 12 minutes at 426 MB/s throughput for SHA-256. The supervisor exports the results as a JSON file, which she formats into the delivery manifest XML. The broadcaster's QC engineer hashes the same files on receipt, compares the SHA-256 strings, and signs off on the delivery without requesting a re-upload. The 312 GB re-upload would have cost approximately 90 minutes on the broadcaster's 600 Mbps ingest line plus a $400 re-delivery fee from the post house.
The JSON export also gives the post house a permanent archival record of exactly which file version shipped, protecting against disputes if a broadcaster later claims a reel was corrupted in their archive.
Example 3: Remote VFX Shot Verification Between Facilities
A VFX supervisor at a London facility needs to confirm that 214 EXR plate files sent via Aspera from a Los Angeles production office arrived without corruption. The files total 88 GB in 16-bit OpenEXR format. The LA coordinator ran SHA-256 on each file before uploading and emailed a text file of expected hashes.
The London supervisor drops all 214 EXRs into the File Checksum Verifier and pastes each expected SHA-256 into the expected hash field one at a time. She uses the CSV export to generate a verification log that both facilities sign off on. 211 files return green verified. 3 files return red mismatch. Aspera's transfer log confirms those 3 files had a network interruption mid-transfer and were not fully re-sent. The LA office re-sends only those 3 files (1.2 GB) rather than the full 88 GB set. Turnaround: 4 minutes instead of approximately 2 hours for a full re-transfer.
The tool's no-upload privacy model means the unreleased EXR plates never touched a third-party server during verification.
File Checksum Tools Compared (2026)
| Tool | Price | MD5 | SHA-256 | SHA-512 | Offline / No Upload | Large File Support | MHL Support |
|---|---|---|---|---|---|---|---|
| Tools for Film (this tool) | Free | Yes | Yes | Yes | Yes (100% browser) | Yes (streaming, 64 MB chunks) | Paste hash from MHL |
| ShotPut Pro 3 | $149 (macOS only) | Yes | Yes | No | Yes (desktop) | Yes | Yes (generates MHL) |
| Silverstack XT (Pomfort) | $89/mo or $649/yr | Yes | Yes | No | Yes (desktop) | Yes | Yes (ASC MHL v2) |
| Hedge (Mac / Windows) | $99/yr | Yes | Yes | No | Yes (desktop) | Yes | Yes (ASC MHL v2) |
| YoYotta | $399 one-time (macOS) | Yes | Yes | No | Yes (desktop) | Yes | Yes |
| HashMyFiles (NirSoft) | Free (Windows only) | Yes | Yes | Yes | Yes (desktop) | Yes | No |
| md5sum / shasum (CLI) | Free (built-in Unix/macOS) | Yes | Yes | Yes | Yes (local) | Yes | No |
| Online MD5 File Hash websites | Free | Varies | Varies | Rarely | No (uploads your file) | Limited (browser memory) | No |
Pro Tips and Common Mistakes
Pro Tips
- Always hash both the source card and the destination copy before ejecting the card. ShotPut Pro and Silverstack do this automatically, but if you are using a manual workflow, compute the SHA-256 of the source card files first, then re-hash after the copy finishes on the destination. If anything in the chain flips a bit during transfer, the destination hash will not match. A 50 GB card takes roughly 2 minutes to hash at SHA-256 speeds in this tool.
- Use SHA-256 as your standard algorithm for everything in 2026. MD5 is still required when your pipeline produces or consumes MHL manifests generated by ShotPut Pro or Silverstack in their legacy formats, but ASC MHL version 2 (the current standard used by Pomfort, Hedge, and YoYotta) supports SHA-256 and xxHash natively. If you are building a new workflow from scratch, skip MD5 and SHA-1 entirely and store SHA-256 alongside xxHash64 for speed cross-checks.
- For files larger than 10 GB, let the tool run uninterrupted. The browser tab must stay active because this tool hashes on the main thread to avoid Web Worker complexities with Next.js. Do not close the tab, lock the screen, or let the browser suspend the tab while a large hash is running. A 50 GB file interrupted at 80% requires a full restart from byte zero.
- Use the JSON export as an archival checksum manifest. Store it alongside your camera reports and sound reports in your project's asset management system. When a delivery dispute arises 18 months later about whether a file was modified after delivery, your JSON export with timestamps and SHA-256 hashes is your proof of chain of custody. This is the same reason facility-level DIT workflows use MHL: every file gets a hash at the moment of creation.
- When verifying an expected hash from a vendor or facility, paste the entire hash string without leading or trailing spaces. The tool comparison is case-insensitive, so a lowercase sha-256 from a Linux shasum command matches an uppercase SHA-256 from a Windows tool. If you get a red mismatch on a file you know should match, check for invisible whitespace or line breaks in the pasted hash before assuming the file is corrupt.
Common Mistakes
- Verifying the hash of a compressed archive instead of the extracted files. A ZIP or LTO tar archive has its own SHA-256 that is different from the SHA-256 of each file inside it. DITs who hash the archive at delivery and then hash the extracted files on arrival will always see mismatches, because archive formats add metadata, directory structure, and compression headers that change the byte sequence. Hash the individual media files, not the wrapper.
- Using an online file hash website for unreleased footage. Any service that computes a checksum by accepting a file upload is sending your footage to a third-party server. For confidential dailies, unreleased episodes, or pre-release features, this is a chain-of-custody breach. This tool runs entirely in your browser with no upload. Use it, or use a command-line tool locally, for any content that has not been publicly released.
- Assuming a matching MD5 means the file is bit-for-bit identical in all scenarios. For everyday corruption detection (transfer errors, bad sectors, network interruptions), MD5 is completely reliable. But if you are working in a security context where an adversary could potentially substitute a file while preserving the checksum, MD5 is not safe. Use SHA-256 or SHA-512 for any workflow where tampering is a concern beyond accidental corruption.
Frequently Asked Questions
What is a checksum and why do DITs use them?
A checksum (also called a hash or digest) is a fixed-length string computed from the bytes of a file using a mathematical algorithm. Any change to even a single bit of the file produces a completely different checksum. DITs use checksums to verify that an offloaded copy of camera footage is byte-for-byte identical to the original card. Without a checksum, there is no reliable way to know whether a file copied correctly or whether a bad sector, network error, or storage failure silently corrupted a frame. Professional DIT tools like Silverstack, ShotPut Pro, and Hedge all use checksums (MD5, SHA-1, or SHA-256) as the core of their verification workflow.
What is the difference between MD5, SHA-1, SHA-256, SHA-384, and SHA-512?
All five are hash algorithms that convert a file into a fixed-length hex string. MD5 produces 32 characters, SHA-1 produces 40, SHA-256 produces 64, SHA-384 produces 96, and SHA-512 produces 128. The longer the output, the harder it is for two different files to produce the same hash (a collision). MD5 and SHA-1 are both considered cryptographically broken for security use because researchers have demonstrated collision attacks, but they remain fully reliable for detecting accidental corruption in film workflows. SHA-256 is the current industry standard for delivery verification. Use SHA-256 or SHA-512 for any workflow where security or tamper-evidence matters.
How long does it take to hash a large camera file?
At SHA-256 speeds using hash-wasm (WebAssembly), this tool processes approximately 426 MB per second on a modern laptop. A 10 GB file takes roughly 24 seconds. A 50 GB file takes approximately 2 minutes. A 200 GB LTO tape's worth of content takes roughly 8 minutes. These figures assume the file is on a fast NVMe or Thunderbolt drive. Files on a spinning hard drive or USB 2 drive will be limited by disk read speed, typically 80 to 150 MB/s, not by the hashing speed.
Can I use this tool to generate MHL files?
The current version verifies individual file hashes by comparing against a hash you paste in. It does not parse or generate MHL XML files. MHL (Media Hash List) is an XML format defined by the ASC MHL specification that bundles hashes for all files in a directory with metadata including creator, date, and file paths. Generating full MHL manifests is planned for a future version. For now, paste the expected hash for each file from your ShotPut Pro, Silverstack, or Hedge MHL report and compare manually.
Why is this safer than online checksum tools?
This tool runs 100% in your browser using the File API and WebAssembly. It calls File.slice() to read chunks from your local disk directly into browser memory. No fetch() or XMLHttpRequest reaches any server. You can verify the behavior by opening your browser's network tab: no outbound requests occur during hashing. Online tools that compute checksums require you to upload your file to their server, which means your footage touches their infrastructure. For unreleased content, that is a potential confidentiality breach and may violate production NDAs.
What happens if I close the tab while a large file is hashing?
Closing the tab or navigating away cancels the hash operation. The computation does not run in a background service worker, so it is not resumable. For files larger than 10 GB, keep the tab active and the browser window in the foreground. On most operating systems, a browser tab that goes to the background for an extended period may have its JavaScript throttled by the browser's power management system, which would slow the hash. If you need to hash a 100 GB or larger file reliably, use a native CLI tool like shasum -a 256 on macOS or certutil -hashfile on Windows, which run as system processes unaffected by browser tab management.
Start Calculating
A single corrupted frame in an undetected bad offload can turn a $4,000 reshoot day into a production-stopping crisis. Checksums cost 2 minutes per camera card and catch that corruption before you release the source media. The File Checksum Verifier gives you SHA-256 and SHA-512 verification in the browser, with zero file upload and zero cost, whether you are a DIT on a union feature or a solo filmmaker offloading cards in a hotel room.
What does your current offload verification workflow look like, and have you ever had a checksum catch a bad copy before it became a problem? Drop your files above, hash them, and export the results as a JSON manifest you can store with your camera reports.
Some links in this post are affiliate links. If you purchase through them, Tools for Film earns a small commission at no extra cost to you. This support helps us keep our calculators and tools free.
