SHA-256 Hash: Prove File Integrity

When you need to prove that a file hasn't been modified (PDF contract, invoice, photo, CSV export, source code, HR file...), you quickly face a simple question: "How do I demonstrate it's exactly the same file?"

That's where the hash (e.g., SHA-256) becomes valuable. It doesn't "prove" the content in a human sense, but it provides a digital fingerprint: if the file changes, the fingerprint changes.

In this guide, we clarify hash ≠ encryption, do a conceptual demo (easy to reproduce), then finish with best practices so your proof holds up better over time — notably via a workflow like hash → timestamp → archive → verify (as LegalStamp offers).

Simple Definition

A SHA-256 hash is a fingerprint calculated from a file.

Input: any file (text, image, PDF, ZIP...)
Output: a fixed string (256 bits, often displayed in hexadecimal, i.e., 64 characters)

The SHA-256 hash is the digital fingerprint of a file: if the file changes, the fingerprint changes.

Hash ≠ Encryption (Key Point)

Encryption: transforms content into unreadable content but reversible (with a key).
Hash: transforms content into a fingerprint not reversible (you can't "un-hash" a file).

The hash doesn't protect confidentiality: it serves to verify integrity.

Common Mistake

A hash (SHA-256) doesn't encrypt a file and doesn't make it "secret". If you need to protect the content, use encryption in addition (and manage the key).

How It Works

The idea rests on three properties useful in practice:

Deterministic: same file → same hash.
Very sensitive: a single byte modified → totally different hash.
Very unlikely to "imitate": finding another file that gives the same hash is considered extremely difficult (it's not "absolute proof", but it's a pillar of digital integrity).

Conceptual Demo

We'll create a file, calculate its SHA-256, modify one character, then recalculate.

1
Calculate the SHA-256 of a file
On macOS/Linux: `shasum -a 256 myfile.pdf` or `sha256sum myfile.pdf`. On Windows: PowerShell `Get-FileHash .\myfile.pdf -Algorithm SHA256` (or `CertUtil -hashfile myfile.pdf SHA256`). Note the value obtained.
2
Modify the file (even minuscule)
Example: open a `.txt` and add a period, or re-export the PDF. Even an invisible change (metadata, internal order) can modify the hash.
3
Recalculate the hash and compare
Use the same command again. You'll notice the SHA-256 is different. Conclusion: the integrity is no longer the same (the file has changed).

Verifying file integrity is recalculating its hash and checking that it's identical to the reference.

Small "Visual" Text Example

Imagine:

contract_v1.pdf → SHA-256 = A1B2...9F
You change a character (or metadata):
contract_v1_modified.pdf → SHA-256 = 7C8D...12

Even if the two PDFs "look alike", the fingerprint changes: this is precisely what we exploit for integrity.

The hash allows comparing without comparing "by eye". You don't need to open the file: you compare two fingerprints, which is fast, automatable, and reliable for detecting alteration.

What It Proves (When Used Well)

That the file verified today is bit-for-bit identical to the one that produced the reference hash.
That there was no modification (even minor) between the two calculations.

What It Doesn't Prove (Good to Know)

The date: a hash alone doesn't say "when" the file existed (if you have a Word document "somewhere", nothing prevents writing it later).
Who calculated the hash (without an authentication/traceability mechanism).
The meaning of the content (a hash doesn't say "this contract is valid", only "this file is identical").

✓

The Combo That Strengthens Proof

To associate a date with the fingerprint (and thus strengthen priority), you add a timestamp: you "anchor" the hash in a timestamping system (for example via a service like LegalStamp, which can rely on blockchain anchors like OpenTimestamps/Bitcoin). You then get: integrity + time reference.

Best Practices

Simple checklist for more robust proofs:

[ ] Keep the original file (don't re-save it if possible).
[ ] Calculate the hash on a final version (e.g., "frozen" PDF, final export).
[ ] Store the hash in a copyable format (plain text) and ideally timestamped.
[ ] Associate the hash with useful metadata: file name, size, type, context, internal identifier.
[ ] Avoid formats that change with each save (some tools automatically modify metadata).
[ ] Set up a verification procedure (who, when, how, where stored).
[ ] For priority: timestamp the hash and archive the timestamping proof (workflow: hash → timestamp → archive → verify).
[ ] For confidentiality: if necessary, encrypt the file separately (the hash alone doesn't protect the content).

FAQ

1) Why SHA-256 and not MD5?

MD5 is historically popular but is no longer recommended for security/integrity robustness purposes in demanding contexts. SHA-256 is more modern and widely used.

2) Does a hash prove that no one can falsify?

It strongly reinforces modification detection, but "complete" proof depends on the context and procedure. We avoid talking about "absolute proof".

3) If I compress the file (ZIP), does the hash stay the same?

No. The hash is based on the exact bytes. A ZIP of the same content is a different file → different hash.

4) Can two different files have the same SHA-256?

In theory, collisions exist for any hash function. In practice, with SHA-256, it's considered extremely unlikely and we use it precisely for its robustness.

5) Can I retrieve the file from the hash?

No. A hash is not reversible: it's a fingerprint, not encryption.

6) Is the hash sufficient to prove a date?

No. The hash proves integrity, not the date. For the date, you need a timestamp (and keep the associated proof).

7) Do I reveal my file's content by sharing its hash?

Generally, no: the hash doesn't contain the content. But if the file is very predictable (short text, known data), someone could calculate the hash of the same document and notice it's identical. If confidentiality is critical, encrypt and control sharing.

8) How does LegalStamp fit into the process?

A common use: you import a file, LegalStamp calculates its hash, timestamps it, then you archive the proof. Later, you can verify that a file matches the timestamped hash (integrity) and show that it existed at a date (time reference).

Conclusion

The SHA-256 hash is the simplest tool to answer a crucial question: "Has this file remained identical?" It doesn't encrypt, doesn't give a date, and says nothing about the legal validity of the content — but it provides a robust and easily verifiable fingerprint.

If your goal also includes priority (proving a file existed at a given time), adopt the workflow hash → timestamp → archive → verify. That's exactly what LegalStamp offers to make the process simple, traceable, and reusable.

Disclaimer (general information): this article is provided for educational purposes and does not constitute legal advice. Depending on your context (litigation, compliance, court evidence), requirements may vary; in case of significant stakes, have your approach validated by a competent professional.

SHA-256 Hash: How to Prove File Integrity (and Why It's Not Encryption)