Checksums are often added to upload protocols with an imprecise promise of “security.” A digest can detect accidental corruption and identify whether two byte sequences match. It does not prove who created a file, whether consent exists, or whether the media is safe to display.
Choose the integrity boundary
Decide which bytes are hashed. The original file selected in the browser, each uploaded part, the assembled object, and a transcoded derivative are different byte sequences. Record separate digests when the system needs to verify each boundary.
For an original-preserving service, the most useful comparison is browser source digest versus assembled storage-object digest. Large files should be streamed rather than copied into one enormous ArrayBuffer.
Understand browser limits
The standard Web Crypto digest API expects the full input buffer, which can cause memory pressure for videos. Incremental hashing requires a carefully reviewed library or a worker implementation. Do not freeze the main thread while presenting a “preparing” spinner.
For small photographs:
const bytes = await file.arrayBuffer();
const digest = await crypto.subtle.digest('SHA-256', bytes);
For large media, hash parts during transfer and compute or verify the final object digest on the server.
Part hashes are not automatically a file hash
Concatenating hexadecimal part hashes does not produce the SHA-256 of the complete file. A multipart storage ETag may also use a provider-specific algorithm. Document exactly what each field represents.
If the protocol verifies every numbered part and the server assembles them in a trusted order, part digests provide transfer integrity. A separate final digest can protect export and handover workflows.
Bind metadata to the digest
A digest by itself has no event, media ID, or algorithm context. Store it with the upload intent and immutable byte length. Include an algorithm version so future migrations do not reinterpret old values.
Do not use a raw digest as a public object key for private media. Someone who already has a common file can test for its presence. Keep identifiers random and authorization separate.
Handle mismatch safely
A mismatch should prevent acceptance and trigger a bounded retry or restart. Preserve a safe reason code and enough part-level evidence to diagnose network or implementation problems. Do not log file contents or signed URLs.
Repeated mismatches from one client version may indicate a hashing bug rather than hostile traffic. Compare across coarse browser and application versions.
Use digests for deduplication carefully
Server-side deduplication can save storage, but cross-event equality leaks information and complicates deletion. Prefer deduplication within one event or one owner boundary. Keep reference counts correct and ensure deleting one media record does not remove bytes still required elsewhere.
Perceptual hashes answer a different question and create additional privacy risks. They should not be introduced as a casual extension of byte-integrity checks.
Verify exports too
The digest recorded at acceptance can appear in an export manifest. The archive builder should hash the exact exported bytes and note when a derivative differs from the original. Recipients can then confirm download integrity.
I help build Gathmo and have a commercial interest in trustworthy media handling. The Gathmo company overview gives product context; these checksum boundaries apply to many upload and archive systems.
A checksum is valuable when its byte boundary, algorithm, storage, and failure behavior are explicit. It is evidence of equality—not a substitute for authorization, moderation, provenance, or consent.
Top comments (0)