Key takeaway
A matching label is not a verification method. Name the expected checksum, algorithm and byte scope before comparing a delivered package.
Ask what the value actually measures
A delivery note supplies a field called hash. The recipient computes an MD5 of the downloaded file, sees a different value and declares corruption. That conclusion is premature if the supplied field is an object-store validator produced by a different method. A comparison needs the same algorithm, representation and byte scope on both sides.
Amazon S3 documents that an ETag may or may not be an MD5 of object data. Multipart uploads and specified server-side encryption paths do not have full-object MD5 ETags. Its API also distinguishes full-object and composite checksum types. Preserve those properties rather than inferring the method from a familiar-looking hexadecimal string.
Compute one complete byte comparison
The following hypothetical package contains a tiny synthetic CSV. Its exact bytes are the UTF-8 text order_id,units, then a line feed, then K17,4, then a final line feed. The changed candidate replaces only the 4 with 8 and keeps both line feeds. Each file is twenty-one bytes; equal size does not mean equal content.
The author computed the full SHA-256 values below from those explicit byte sequences. If the first file is the approved expected artifact, the changed candidate fails that byte-identity check. The calculation is an actual local check of invented inputs. It is not a test of a cloud provider or a real company delivery.
The expected value must come through an appropriate trusted release record. Recomputing both a new file and its new manifest after an unexplained change can show agreement between those new artifacts while failing to establish that either matches what was approved.
| Synthetic bytes | Length | Computed full SHA-256 |
|---|---|---|
| order_id,units LF K17,4 LF | 21 bytes | ecc5f4fe37a02c9009eff00f5c28a2d15c3fec223c79b827986106dfa0bc7ea8 |
| order_id,units LF K17,8 LF | 21 bytes | 94b7bcf755863490672f5d4c1ba99bf02a40852623067905e2deff6f5f4407a3 |
Classify an inapplicable comparison separately
In a second fictional case, an S3 object was created through Multipart Upload and its ETag was copied into a manifest column labeled MD5. A different local MD5 does not, on that evidence, establish corruption: the expected field was misclassified. The decision is to hold the verification claim and obtain an applicable checksum, not to announce that the file passed.
A partial read needs a partial claim
Google Cloud Storage similarly documents checksum differences across upload modes, including cases where MD5 is not supported. Its validation guidance describes comparing the stored checksum with one computed over received data. The whole-file expectation and the bytes actually read must correspond.
A recipient that downloaded only one range cannot compare a checksum of that range with a full-object checksum as if they described the same bytes. Retain a partial-read status or use a supported integrity mechanism for that path. Combining ranges needs an inspected full-byte coverage and assembly procedure before the final whole-object comparison.
| Illustrative evidence | Decision | Missing fact |
|---|---|---|
| Matching full SHA-256; same complete bytes | Byte-identity check passes | Other release conditions remain separate |
| Changed CSV with different full SHA-256 | Hold mismatch | Explain or replace the candidate |
| Multipart ETag treated as whole-file MD5 | Comparison inapplicable | Correct method and expected value |
| One range versus full-object checksum | Coverage incomplete | Complete bytes or supported range validation |
Keep the verification receipt reproducible
A useful receipt names the object/version, expected-value source, algorithm, checksum type, encoding, byte length, receiving method, actual computed value and comparison outcome. Record whether any content decoding, decompression, newline conversion or reserialization happened before computation. Those operations can produce a different artifact even when its displayed information looks equivalent.
For the two CSVs, the byte contract explicitly includes the final line feed. A consumer that removes it has produced another byte sequence and needs a different comparison boundary. That does not necessarily make the derivative unusable; it makes a claim of unchanged approved bytes unsupported.
Treat mismatch, inapplicable method and incomplete coverage as separate states. Each asks for different corrective work. A mismatch asks which bytes changed; an inapplicable comparison asks for the right method; incomplete coverage asks what was actually read.
Accept integrity without expanding its meaning
The completed fixture accepts only the original CSV against its original full SHA-256. It holds the changed CSV, the misclassified ETag comparison and the unverified range. Save those outcomes with the package identity so a later retry cannot silently replace the failed evidence.
Keep the integrity receipt beside the approved package manifest. Ask for the missing algorithm, expected-value source or complete-byte coverage directly instead of requesting another unexplained hash. Byte agreement remains separate from authorship, factual accuracy, harmful content and rights to disclose the file.