How SHA-256 Hashing Helps Detect File Changes

Key points

• SHA-256 maps a file's bytes to a 256-bit digest, commonly displayed as 64 hexadecimal characters.
• Matching digests strongly support that the compared bytes match; a different digest means the bytes differ.
• A digest cannot show whether a scene was truthful, when a file was first created, or what happened outside the file.
• Record the algorithm, exact source object, calculation event, and protected reference; hash derivatives separately.

Diagram in words

An original file is hashed with SHA-256 and produces a 64-character reference digest. Later, the exact object is hashed again. A matching digest supports byte-for-byte consistency with the trusted reference; a mismatch detects different bytes and requires investigation. Neither result validates the recorded scene.

What SHA-256 produces

SHA-256 is one algorithm in the SHA-2 family. It accepts input of arbitrary length and produces a 256-bit result, usually written as 64 hexadecimal characters. A digest might look like this fictional, shortened display:

9f2a…7c41

Do not shorten the stored reference. A review system should retain the complete digest and name the algorithm as SHA-256. The same 64-character shape can be confusing without that label, and a fragment is not enough for a proper comparison.

NIST's current hash-functions overview lists SHA-256 in the SHA-2 family defined by FIPS 180-4. NIST describes approved hash functions as designed for collision resistance, preimage resistance, and second-preimage resistance. In plain language, finding different input with the same digest is intended to be computationally infeasible—not logically impossible.

For shipment records, the practical comparison is simple:

The reference needs an origin and a time

A digest becomes useful evidence only in context. Record at least:

• the algorithm (SHA-256);
• the complete digest;
• the exact file or object that was hashed;
• when the service calculated or received the value;
• which system performed the calculation; and
• how the reference was protected from silent replacement.

Suppose a phone records a packing video on Monday, but a service first receives and hashes it on Thursday. A later match supports consistency with the Thursday reference. SHA-256 alone does not reconstruct the Monday-to-Thursday interval. A participant or device may report an earlier creation time, but that is a separate source claim.

Calculating the digest as close to controlled receipt as practical reduces the unreferenced interval. It does not make events before receipt visible.

Hash the exact object you intend to verify

Small changes to a digital object produce a different digest. That includes changes a viewer may not notice:

• editing one visible pixel or video frame;
• changing embedded metadata;
• exporting or recompressing a video;
• rotating and resaving an image;
• adding a redaction;
• extracting a still frame; or
• changing a container or file representation.

The changed digest does not mean the visible subject necessarily changed. It means the bytes are different.

This is why “the evidence hash” is too vague. A source video, compressed preview, thumbnail, transcript, and PDF export are separate objects. Give each its own reference and link derivatives to the original. The source-linked record framework explains how to preserve that relationship.

A five-step integrity pattern

PackProof recommends this bounded workflow for a retained source file:

1. Identify the object. Assign a stable object or entry ID and connect it to the correct order or transaction.
2. Calculate on controlled receipt. Record the SHA-256 digest when the system receives the file, before creating convenience copies where practical.
3. Protect the reference. Store the digest and calculation event in a system where later replacement is controlled and logged. Protecting only the file while leaving the reference freely editable weakens the comparison.
4. Track derivatives. Preserve the original where policy permits; identify every crop, export, preview, redaction, or transcript as a derivative with its own digest.
5. Verify before relying on a copy. Recalculate the digest for the exact object under review and compare the complete value. If it differs, stop describing the copy as byte-identical and investigate the file history.

NIST IR 8387 recommends hashing digital images and other objects and storing resulting hashes separately in a secure location. It also identifies important failure modes: a file can change before hashing, and someone able to replace both evidence and its stored hash can make a later pair appear consistent. The publication is guidance for evidence handlers, not a product endorsement or a rule for every commerce dispute.

Interpret a mismatch carefully

A mismatch is a detection result, not a motive detector. Start by confirming that the comparison used:

• the same algorithm;
• complete values with no missing or copied characters;
• the intended source object rather than a preview;
• a correctly transferred file; and
• the intended trusted reference.

Then inspect ordinary transformations and storage events. Messaging apps may recompress media. An image editor may rewrite metadata during rotation. An export may use a different container. Corruption or an incomplete transfer can also change bytes.

If a derivative was expected, compare it with its own recorded reference and follow its link to the source. Never “fix” a mismatch by overwriting the old digest with a new one. Record a new calculation event and preserve the earlier reference and investigation notes.

A matching digest is not scene authentication

Consider a recording that clearly shows a sealed parcel. A matching SHA-256 digest can support that the reviewed file matches the referenced file. It cannot establish that:

• the correct item was shown before the recording began;
• the scene was not staged;
• the device clock was accurate;
• the visible item was authentic;
• no relevant action occurred outside the frame;
• the parcel remained unchanged after recording; or
• a carrier or marketplace will accept the file.

Those are source, coverage, chronology, identity, and policy questions. The broader digital evidence trustworthiness guide keeps those checks separate.

The reverse matters too. A file with no hash reference may still contain useful visible information. It simply lacks that particular byte-level comparison to an earlier state. Describe the missing control rather than treating it as automatic proof of tampering.

Preserve the algorithm label and migration context

NIST's FIPS 180-4 page says the standard specifies hash algorithms whose digests can detect whether messages changed after the digests were generated. The page also carries a March 7, 2023 planning note that NIST decided to revise FIPS 180-4. As of the October 24, 2026 review, NIST's current hash-functions overview still lists SHA-256 among the approved SHA-2 algorithms.

A long-lived record should therefore name the algorithm instead of storing an unlabeled “checksum.” If an organization later adopts another approved algorithm, retain old references with their original labels and create new calculation events where appropriate. Do not rewrite history to make earlier records appear to have used a later method.

SHA-256 is strongest as one control inside a transparent record: the file has an identity, the calculation has a time and system source, the reference is protected, derivatives remain linked, and the review states exactly what a match can support.

Sources

Technical sources reviewed October 24, 2026. The five-step integrity pattern and shipment examples are PackProof editorial guidance.

• NIST: Hash Functions overview
• NIST: FIPS 180-4, Secure Hash Standard
• NIST: Digital Evidence Preservation, NIST IR 8387

See the record in context.

Explore how PackProof connects the order, available evidence, and shipping activity.

Review the integration model →