Free tool
Check a DCP in your browser
Every DCP carries its own checksums: the Packing List, or PKL, stores a SHA-1 for each asset. This page recalculates them on your computer and shows which files still match. Nothing is uploaded, there is no account and nothing to install.
By asa cinema · updated 22 September 2026
Drop your DCP folder here
or choose it below. SMPTE and Interop packages both work.
| File | Checksum in the PKL | Checksum here | Result |
|---|
What a match tells you
A match means the files on your disk are the ones this PKL describes. It does not mean the package is correct: a badly mastered DCP stays consistent with its own PKL, because the PKL was written from those same files.
For the files it covers, a match at the time of the check rules out the usual transport accidents: a copy that lost a few bytes, a download that stopped early, an archive that did not unpack properly.
What is and is not checked
Checked
- Every asset listed in the PKL is present in the folder you chose.
- Its SHA-1, recalculated byte by byte, matches the
Hashfield of the PKL. - Its size matches the
Sizefield. - ASSETMAP and PKL are read in both the SMPTE and the Interop formats.
Not checked
- Conformance to the standard: reel structure, CPL consistency, XML schemas, naming, frame rates. That is the job of a full validator.
- Whether the film will play on a given server with a given key.
- Encryption and KDMs. An encrypted package is checked the same way; the key is not examined.
- Files the PKL does not list.
If an asset is missing or cannot be read, the page does not show a green result. An incomplete check is reported as incomplete.
How it works
The PKL of a DCP lists each asset with its size and a SHA-1 checksum encoded in base64. Cinema servers can use these values at ingest, recalculating the checksums and rejecting the package if one differs. That is usually what a "checksum error" on a projection server means.
This page does the same thing before you send. It reads the ASSETMAP to find which file belongs to which asset, reads the expected checksums in the PKL, then passes each file through SHA-1 in a background worker, 8 MB at a time. A 100 GB MXF is never loaded into memory in one piece, and the page stays usable while it works.
The speed you see is the speed of your disk, not of your connection. No file is uploaded and no result is sent anywhere. The only thing fetched from outside is the hashing library, hash-wasm, at a fixed version.
If a file does not match
Copy that file again from the original, and check again. A mismatch means the file you have is not the file the PKL was written for: something changed it after mastering.
If every file mismatches, look at the PKL instead. You may be checking the files against the PKL of another version of the package.
"Invalid PKL file Name": when a valid DCP is refused
An ingest tool can refuse a DCP that is complete and valid. We met this message in September 2026:
Invalid PKL file Name
The PKL referenced in your DCP ASSETMAP was not found on disk.
Please check your DCP and try again.
The package was a feature made with DCP-o-matic 2.18.43. The recipient had downloaded it in full, and a structural check with ClairMeta found it conformant. In the package as delivered, the ASSETMAP pointed to the PKL under its exact name.
Our best lead is the case of the file name. DCP-o-matic writes most file names in
lowercase: pkl_…xml,
cpl_…xml, j2c_…mxf, pcm_…mxf, while
ASSETMAP.xml and VOLINDEX.xml are in capitals. The SMPTE standard
does not require either case. What matters is that each <Path> in the
ASSETMAP matches a file in the folder, and here it did. Many packages come from tools that
write PKL_ and CPL_ in capitals, and an ingest tool may have been
written to expect that. We have not confirmed that this was the cause.
Renaming the PKL in capitals is quick and needs no re-encoding, as long as you change two things together:
- Rename the file, for example
pkl_1a2b3c4d-….xmltoPKL_1a2b3c4d-….xml. - In
ASSETMAP.xml, change the matching<Path>line to the new name.
This is safe because the PKL holds checksums for the other assets, the CPL and the MXF files, and none for itself or for the ASSETMAP. Checksums cover file contents, not file names, so renaming breaks none of them. What does break the package is renaming the file without updating the ASSETMAP: it then points to a file that no longer exists. Whether the renamed package clears the error depends on the tool, so ask the recipient to tell you the result.
If the package came with an ASC MHL manifest, the manifest lists files by name. After the change, the entries for the PKL and the ASSETMAP will no longer match. That is expected: the MXF files, which hold the picture and sound, stay verifiable.
After the check
This check covers the copy on your computer. After the transfer, your recipient needs to check the files saved on their side, with a tool of their choice, using a delivery manifest. How to verify a copy with an ASC MHL manifest (in French, with two real examples to download).
If you would rather have the check done automatically at the other end: how sweep sends a DCP (in French).