Detecting and Documenting Digital File Changes

Detecting and Documenting Digital File Changes: A Practical Guide to Proving What Changed and When

A file has changed if even one byte inside it is different. The reliable way to detect that is to compute a cryptographic hash, such as SHA-256, of the file at one moment and compare it with the hash of the same file later. If the two values match, the content is identical. If they differ, something has changed. Documenting the change means recording each hash with a trustworthy timestamp, so the history of the file can be checked by someone who wasn’t there.

That second part is where most people come up short. Spotting a change is easy. Showing a client, an auditor or a court-appointed expert that your record of the change is itself believable is the harder problem.

Why “date modified” doesn’t settle anything?

Open a file’s properties and you’ll see a “last modified” date. It’s tempting to treat it as evidence. It isn’t, for a few reasons.

That date is metadata stored by the operating system, and it is easy to edit. Copying a file between drives, extracting it from an archive, syncing it through a cloud service or restoring it from backup can all reset or rewrite it. Going the other way, a file can be altered and have its modified date put back by a few lines of script.

It also fails in the opposite direction. Plenty of changes that matter leave the visible content untouched, and plenty of “changes” involve nothing a reader would care about. The date tells you what the system last wrote down, not what the file contains.

What you want is a measurement of the content itself. That is what a hash gives you.

What a hash does, in plain terms

A cryptographic hash function reads every byte of a file and produces a fixed-length fingerprint. SHA-256, defined in NIST’s FIPS 180-4 standard, always produces 256 bits, usually written as 64 hexadecimal characters, whether the input is a one-line text file or a 4 GB video.

Two properties make it useful for change detection.

First, it’s deterministic. The same bytes always give the same fingerprint, on any computer, with any tool that implements the standard correctly.

Second, it is extremely sensitive. Change one character, one pixel value or one bit, and the output looks completely unrelated to the original. This is often called the avalanche effect. For reference, the published test vector for the three-character input “abc” is ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad. Change that input to anything else, even by one letter, and you get a wholly different string, with no visible resemblance and no hint about where the difference was.

That last point matters for what comes later: a hash tells you that a file changed, never what changed.

The “I only opened it” problem

Here’s where real-world use gets messy. Hashes are judged against bytes, not against what a human sees on screen. So a file can produce a different hash without any meaningful edit.

Some common culprits:

* Re-saving an office document: Opening a Word, Excel or PowerPoint file and saving it again often rewrites internal structure, timestamps and metadata. The document looks identical, but the bytes aren’t.

* PDF re-exports: “Print to PDF” from the same source twice can generate different bytes, because creation dates and internal identifiers are embedded in the file.

* Image handling: Re-exporting a JPEG recompresses it. Some apps strip or rewrite EXIF data when you share a photo.

* Line endings and encoding: A text file moved between Windows and Linux systems may switch between different line-ending conventions, and any change in character encoding alters the bytes.

* Email and messaging: Some channels recompress or re-wrap attachments.

None of these are errors. They’re the reason a documented hash should always be tied to one specific file, stored once, and handled as an artefact. If you want to prove that a contract was in a certain state, hash the exact file you intend to keep, not a copy you’ve opened and saved a few times in between.

The reverse is also useful to know. If a hash does match, you can be confident the content is bit-for-bit identical, regardless of what the filename, folder or modified date says.

Detecting changes: the simple version

For a one-off check, the process is short:

1- Compute the hash of the file when you consider it final.

2- Store that value somewhere separate from the file.

3- When you need to check, compute the hash again from the file as it exists now.

4- Compare the two values character by character.

Most operating systems have built-in tools for step one. On Windows PowerShell, Get-FileHash does it. On macOS and Linux, shasum -a 256 or sha256sum will. Browser-based tools can do the same job without a command line.

If you’re monitoring many files, say a folder of research data or a set of compliance records, you can do this in bulk: generate a manifest listing every filename with its hash, then re-run the process later and diff the two manifests. Anything that differs, appears or disappears shows up straight away.

Documenting changes: where a plain hash falls short

A stored hash only helps if the person looking at it believes it was stored when you say it was. On your own laptop, in your own notes, that’s an assertion rather than evidence. Anyone can compute a hash today and claim it dates from last year.

So documentation has two jobs. It must record the state of the file, and it must make the timing of that record hard to fake.

Traditional approaches handle the second job in a few ways. A trusted third-party timestamping authority can sign a hash with its own key and time, following the format in RFC 3161. A version-control system such as Git records a chain of commits, though the dates in a repository you control are still only as trustworthy as you are. A notary or a registered mail trail can fix a date for a physical copy. Each has uses, and each rests on trusting a particular party to be honest and to survive.

Anchoring a hash on a public blockchain takes a different route. The hash is written into a record whose time ordering is established by a distributed network instead of a single company. Anyone can look the record up later without asking permission from whoever created it.

Treating versions as a chain

The most useful habit for documenting change is to treat each version as its own record, not as one file that “has a history.”

Say a report goes through three important states: a first draft shared with a colleague, a revised version sent to a client, and a final signed-off edition. If you hash and timestamp each one when it exists, you end up with three independent fingerprints with three independent times. Later, you can show that version two existed before the client meeting, that version three differs from version two, and roughly when the difference first appeared on record.

A few practical habits make this much stronger:

* Keep a short written note with each record saying what the version is and why it was made.

* Record the hash of the previous version alongside the new one, so the sequence is explicit.

* Never overwrite an earlier version. Store it under a new name and leave the old one untouched.

* Hash the file at the moment of creation or hand-off, not weeks later when you remember.

This costs a few minutes per version, and it is much cheaper than reconstructing a timeline from memory during a dispute.

How Certelo handles the recording step?

Certelo is built around this exact two-step pattern. When you create a record, the SHA-256 hash is calculated locally, so the original file stays on your device and doesn’t need to be uploaded just to create the proof. That hash is then anchored to the Electra Protocol blockchain, producing a record that supports the claim that this fingerprint existed at or before the recorded blockchain time.

For change documentation, this has a few practical consequences. You can timestamp sensitive drafts, unreleased designs or confidential contracts without handing the content to anyone. Each version gets its own anchored record, which suits the chain-of-versions approach above. And later verification works from the file itself: you hash the file again, and the result either matches an anchored hash or doesn’t.

What a matching or mismatched hash can and can’t tell you

It helps to be exact about the limits, because overstating them is how good evidence gets undermined.

A match shows that the file you’re holding is identical to the file that was hashed. Combined with an anchored record, it supports the statement that this exact content existed at or before the recorded time.

A mismatch shows that the files differ. It doesn’t show who changed it, why, whether the change was deliberate, or whether it’s meaningful. It could be a malicious edit or a harmless re-save.

Neither result proves authorship, ownership or originality. A timestamp says nothing about who made the file. Someone else could, in principle, anchor a copy of your work before you do, which is a reason to timestamp early and not rely on a later record to settle things.

No earlier record means no earlier proof. If you only anchor the file after a dispute starts, you can show its state from then on, not before. Detection is retroactive, but documentation isn’t.

Whether any of this counts as admissible or persuasive evidence depends on the jurisdiction and the circumstances. In the EU, for instance, eIDAS (Regulation (EU) No 910/2014) gives specific legal effect to qualified electronic timestamps, which is a defined category with its own requirements. A blockchain timestamp isn’t automatically that. If your situation turns on legal weight, ask a lawyer in the relevant jurisdiction.

Finding out what changed

Because a hash only says “different,” you need other tools to see the difference.

For text and code, a diff tool or version control will show line-level changes. For office documents, built-in compare features or tracked changes can help. For binary files and images, you’ll usually need a specialised comparison tool, or you’ll rely on having the earlier version available to open side by side.

This is why keeping each anchored version, and not just its hash, matters. The hash proves which version is which. The files themselves let you work out the difference.

Checking a file against its record

When you need to confirm a file against a Certelo record, the logic is straightforward. Take the file you want to check, compute its SHA-256 hash, and compare it with the hash recorded on the blockchain. If they match, the file is identical to the one that was originally recorded. If they don’t, the file you have isn’t the same as what was anchored, and you’d look for the correct version or investigate what happened.

Because the blockchain record is public, the comparison doesn’t depend on Certelo’s cooperation or even on its continued existence.

A short, honest checklist

If you take only a few things from this guide:

> Don’t trust modified dates as evidence of anything.

> Hash the exact file you intend to preserve, and keep that file untouched.

> Record each important version separately, at the time it exists.

> Pair each hash with a timestamp that someone else can verify.

> Keep a short note explaining each version.

> Be clear, when presenting this, about what the record shows and what it doesn’t.

To clarify more

Can a hash tell me what was changed in a file?

No. It only shows whether the content is identical or different. To see the actual change, you need the earlier version and a comparison tool.

Why did my file’s hash change when I didn’t edit anything?

Opening and re-saving, re-exporting, or moving a file between systems can rewrite metadata, compression or encoding. The visible content looks the same, but the bytes differ, so the hash does too.

Does a matching hash prove I created the file?

No. It shows that a specific file matches a specific fingerprint. It doesn’t identify who made it.

Do I have to upload my file to Certelo to document a change?

No. The SHA-256 hash is calculated locally on your device, and the original file isn’t uploaded merely to create the record.

Is a blockchain timestamp the same as a legally qualified timestamp?

Not automatically. Qualified electronic timestamps are a defined legal category in the EU under eIDAS, with specific requirements. A blockchain record can be useful supporting evidence, but its legal weight depends on jurisdiction and context.

What if I only record the hash after a dispute begins?

Then the record shows the file’s state from that point onward. It can’t prove what the file looked like earlier, which is why recording versions as they are created is so much more useful.

Can I check a file years later?

Yes, as long as you still have the exact original file and the record details. Hash the file again and compare it to the anchored value.