Checksum manifest builder & verifier
Did every byte arrive?
Check a received delivery against its .sha256 or .md5 manifest and see exactly which files changed, which are missing and which nobody listed. Or generate a manifest for a package you’re sending, in the format sha256sum -c reads. Files are hashed in your browser, one at a time, however large. Nothing is uploaded.
1. The manifest
2. The files it describes
Choose the delivery to check
Or drop a folder or files here. Files are read in your browser and never uploaded.
Choose the delivery to describe
Or drop a folder or files here. Files are read in your browser and never uploaded.
What a matching checksum proves, and what it doesn’t
A match proves one thing: the bytes of that file are the bytes the manifest describes. If the manifest is the one the sender made, the file came through the transfer unchanged.
It does not prove:
- Who made the manifest. Anyone who can change the files can write a new manifest to match. A checksum checks transport, not authorship; that needs a signature, or a manifest that reached you by a separate, trusted route.
- That the package is complete. It covers only what the manifest lists. Files the sender left out of the manifest are invisible to it, which is why this tool reports unlisted files rather than ignoring them.
- That the media is any good. A corrupt master hashed before it was sent verifies perfectly. Checking the content is a QC job: start with the file header reader.
SHA-256 or MD5?
Use SHA-256 unless a workflow insists on MD5. MD5 still catches accidental corruption reliably, since a flipped bit in transit will not happen to produce a matching digest. But it is broken against anyone trying to make two files match: collisions can be produced deliberately, and RFC 6151 retires it for anything that relies on collision resistance. An MD5 match against a manifest you trust is fine for transfer checks and means nothing more.
The format
Manifests are written the way GNU coreutils writes them: one line per file, the hex digest, two spaces and the path relative to the delivery folder, sorted byte by byte so two manifests can be diffed. Filenames containing a backslash or a line break use coreutils’ escaped form. When verifying, the tagged form (SHA256 (file) = …, from --tag, shasum and BSD md5) is read too.
Folders are listed through their files: an empty folder has nothing to hash and doesn’t appear. Hidden system files such as .DS_Store are shown and suggested for leaving out, never dropped silently.
This is not an ASC MHL tool. MHL is a different, XML-based format with its own history and chain files, and it isn’t produced or read here.
Related: IMF & DCP package viewer (checks a package against its own packing list) · file header reader · video file size calculator.