A checksum is a fixed-length digest computed by running a file’s full contents through a hashing algorithm \u2014 commonly MD5 for speed or SHA-256 for stronger collision resistance. Any change to the underlying bytes, down to a single flipped bit, produces a completely different checksum, which is what makes it useful as an integrity check: compute it once at upload, store it, and recompute it later to confirm the file is still exactly what was originally stored.<\/p>
DAM platforms rely on this at several points in an asset’s lifecycle: verifying an upload completed without network corruption, confirming a file survived a storage migration or cloud-region move unchanged, and detecting exact-duplicate uploads so the same master isn’t stored twice under different filenames. For archival masters especially, a stored checksum gives a way to periodically audit that cold storage hasn’t silently degraded the file \u2014 a real risk over years-long retention periods.<\/p>
Checksums verify integrity, not similarity or authenticity. Two genuinely different files that happen to depict the same subject will never match, and a checksum match says nothing about who is authorized to use the file \u2014 it only confirms the content is byte-for-byte what it was when the checksum was first recorded.<\/p>","protected":false},"excerpt":{"rendered":"
A short fixed-length value computed from a file’s contents, using an algorithm like MD5 or SHA-256, used to confirm a file wasn’t corrupted or altered during transfer or storage.<\/p>\n","protected":false},"author":0,"featured_media":0,"template":"","meta":{"footnotes":"","faq":[{"question":"What is a checksum?","answer":"A checksum is a short, fixed-length value that a hashing algorithm\u2014typically MD5 or SHA-256\u2014computes from a file's raw bytes. It acts as a unique digital fingerprint: two identical files always produce the same checksum, while changing even a single byte produces a completely different value. DAMs compute checksums at ingest, then recheck them after transfer, migration, or transcoding to confirm the file's contents weren't corrupted or altered along the way."},{"question":"Where does a DAM use checksums?","answer":"At upload to confirm no network corruption occurred, after a storage migration or cloud-region move, and to detect exact-duplicate uploads so the same master isn't stored twice under different filenames."},{"question":"Does a matching checksum mean two files are the \"same asset\" for licensing purposes?","answer":"No. It only proves the bytes are identical. A re-exported file with one pixel or one metadata field changed produces a completely different checksum even though it's visually and editorially the same photo."},{"question":"What's the difference between MD5 and SHA-256 checksums?","answer":"MD5 is the older algorithm: it's fast to compute and produces a 128-bit hash, but it's cryptographically broken\u2014attackers can deliberately craft two different files that share the same MD5 checksum (a collision). That makes MD5 fine for catching accidental corruption but unsafe wherever someone might intentionally forge a match. SHA-256 is newer, produces a 256-bit hash, and has no known practical collision attacks\u2014making it the standard for integrity checks in security-sensitive contexts, including archival storage validation."},{"question":"Can checksum-based dedup catch a resized or recompressed re-export?","answer":"No. A checksum compares a file's raw bytes, not its visual content, so it only detects files that are byte-for-byte identical. Resizing an image or recompressing it re-encodes the pixel data and rewrites the file's byte stream from scratch\u2014so even though the photo looks the same to the eye, its checksum comes out completely different from the original master. Checksum-based deduplication therefore treats a resized or recompressed re-export as an unrelated file; catching that kind of near-duplicate requires perceptual or visual-similarity comparison instead."},{"question":"Why are checksums useful for archival masters specifically?","answer":"Archival masters are typically written once and left untouched in cold storage for years, with no routine access to reveal problems. Storage media itself can silently degrade over that time\u2014a phenomenon called bit rot, where individual bits flip due to disk, tape, or hardware wear without triggering any visible error. Because the file was checksummed at ingest, a DAM can periodically recompute that checksum and compare it against the stored value; a mismatch flags corruption while a clean backup copy may still exist."}],"checked_date":"2026-08-11","sources":[{"statement":"SHA-256 is a secure hash algorithm standardized by NIST that produces a 256-bit condensed digest of a message, and any change to the input results, with very high probability, in a different digest.","source_name":"NIST FIPS 180-4 \u2014 Secure Hash Standard (SHS)","url":"https:\/\/nvlpubs.nist.gov\/nistpubs\/fips\/nist.fips.180-4.pdf","checked":"2026-08-07"}],"kicker":"","fact_checker":0,"reading_time":0,"revisions":[],"seo_title":"Checksum in DAM: MD5 and SHA-256 for file integrity checks","seo_description":"","noindex":false,"related":[2482,2440,2485,2556,2582,2475],"definition":"A short fixed-length value computed from a file's contents, using an algorithm like MD5 or SHA-256, used to confirm a file wasn't corrupted or altered during transfer or storage.","why":"DAM systems move large binary files \u2014 multi-gigabyte video masters, RAW photography \u2014 across networks, storage tiers, and cloud regions constantly, and a checksum computed at ingest and re-checked after upload, migration, or transcoding confirms the bytes arrived intact without anyone having to open and visually inspect the file. It's also the mechanism many DAM dedup engines use to detect that two differently named uploads are actually the identical file.","example_rows":[{"field":"Original file, upload complete","values":"SHA-256: 9f86d0...b2b8b0"},{"field":"Same file, post-migration","values":"SHA-256: 9f86d0...b2b8b0 \u2192 match, integrity confirmed"},{"field":"Corrupted transfer","values":"SHA-256: 4a7d1e...d3d5c0 \u2192 mismatch, re-upload required"}],"mistake":"Teams treat a matching checksum as proof two files are \"the same asset\" for licensing or rights-tracking purposes, when it only proves the bytes are identical \u2014 a re-exported file with one pixel or one metadata field changed produces a completely different checksum even though it's visually and editorially the same photo, so checksum-based dedup misses near-duplicates that a perceptual or visual-similarity check would catch.","deep_link":""},"silo":[24],"class_list":["post-2472","glossary","type-glossary","status-publish","hentry","silo-glossary"],"_links":{"self":[{"href":"https:\/\/picajet.com\/articles\/wp-json\/wp\/v2\/glossary\/2472","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/picajet.com\/articles\/wp-json\/wp\/v2\/glossary"}],"about":[{"href":"https:\/\/picajet.com\/articles\/wp-json\/wp\/v2\/types\/glossary"}],"version-history":[{"count":3,"href":"https:\/\/picajet.com\/articles\/wp-json\/wp\/v2\/glossary\/2472\/revisions"}],"predecessor-version":[{"id":3472,"href":"https:\/\/picajet.com\/articles\/wp-json\/wp\/v2\/glossary\/2472\/revisions\/3472"}],"wp:attachment":[{"href":"https:\/\/picajet.com\/articles\/wp-json\/wp\/v2\/media?parent=2472"}],"wp:term":[{"taxonomy":"silo","embeddable":true,"href":"https:\/\/picajet.com\/articles\/wp-json\/wp\/v2\/silo?post=2472"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}