How to Check Whether a File Has Been Altered

What a hash tells you

A cryptographic hash turns a file of any size into a short fixed-length string. SHA-256, defined in NIST's Secure Hash Standard (FIPS 180-4), produces 64 hexadecimal characters, and changing a single byte of the input produces a completely different result. The standard is built so that finding two different files with the same hash is not feasible in practice. That makes a hash a fingerprint: if two files hash the same, they are the same bytes; if the hashes differ, something in the file differs, even if it is only a space.

The limitation is just as important. A hash tells you that two copies differ. It cannot tell you what changed, who changed it, or when. And it needs something to compare against: a copy you kept, a hash you wrote down earlier, or a hash the publisher listed next to the download.

Compute a SHA-256 hash on Windows, macOS and Linux

Compare the two strings character for character, or paste both into a text editor and use its find function. Case does not matter. Hashes of copies on different machines match perfectly if the files are identical, whatever their filesystem dates say, which is why a hash is the cleanest answer to the question this guide is about.

Check if a file has been altered, step by step

1. 01

   Decide what you are comparing against

   A hash needs a reference. Options are a copy in a backup snapshot, an email attachment you sent, a version from cloud history exported to disk, or a hash you recorded when you finished the work. Without any of these, skip to the metadata and content checks below.

2. 02

   Hash both copies

   Run the command for your system on the file in question and on the reference. Save the output in a text file with the date and the full path of each file.

3. 03

   Compare the results

   If they match, the files are byte-identical and no further checking is needed. If they differ, the rest of the steps find out how.

4. 04

   Run a document compare

   Word processors can compare two documents and mark every insertion and deletion. In Word, open the Review tab and choose Compare; in cloud editors, the version history panel shows changes between any two versions. Most PDF readers have a Compare Files tool. For plain text, a diff utility does the same.

5. 05

   Read the edit metadata

   Open File, Info in an Office document for the last saved date, last modified by, revision number and total editing time. Open File, Properties in a PDF for the modification date, the creating application and the producer. A producer name that differs from the original application is a sign the PDF was re-saved.

6. 06

   Check photos separately

   For an image, read the EXIF Software tag and the modification date with the method in the photo metadata guide, then drop the file onto the public verify page described in the Content Credentials checking guide. A credential that no longer validates means the bytes changed after signing.

7. 07

   Record what you found

   Write down the two hashes, the tool used, the date, and the specific differences the compare showed. A short factual note is what a reviewer or a colleague can act on.

Checks by file type

What a mismatch does and does not prove

A hash mismatch proves that the two files are not the same bytes. It does not prove that the content changed in any way a person would notice. Opening a document and saving it without typing, re-exporting a PDF, letting a cloud client re-encode an image, or a photo app rewriting a thumbnail all produce a new hash. Run the document compare before drawing any conclusion, and treat a mismatch with no visible difference as a re-save until something shows otherwise.

Metadata cuts the other way. Edit counts, author names and dates inside a document are stored as plain values that many tools can rewrite. Microsoft's support page on file properties says the author, title and similar fields are editable from inside the app, while the dates and statistics are updated automatically, and nothing stops other software rewriting either kind. They are a useful narrative when they agree with the hash and the compare, and a weak argument on their own. The same holds for Content Credentials: the C2PA explainer states that validation checks whether the record is intact and signed by a trusted party, and makes no judgment about whether the content is true.

Two more limits. A file with no reference copy cannot be hash-checked; the most you can do is read its internal history and look for inconsistencies such as a creation date later than the last save. And a matching hash proves the file is unchanged since the reference was made, which says nothing about what happened before that.

Common mistakes

• Hashing the wrong thing. A hash of an exported PDF says nothing about the source document. Compare like with like.
• Comparing a cloud copy with a local one. Some sync clients rewrite files on the way down. Hash the copy you actually intend to rely on.
• Treating a re-save as tampering. Run the compare first. No visible change plus a new hash is almost always a re-save.
• Trusting a hash from an untrusted source. A hash printed on the same page as a modified download proves nothing. The reference has to come from somewhere the file's editor could not touch.
• Forgetting to record the reference hash in the first place. The check only works if you kept one. Make it part of finishing a piece of work, alongside the version history habit.

Once you can check if a file has been altered, the next question is usually when it began, which the guide to reading and corroborating a file's creation date answers, and whether an old copy exists, which is where dated backup snapshots come in. Both sit in the site's authorship record collection.

More task guides sit in the task-based laptop guides. A hash answers whether a file changed; for a photo, validating a signed Content Credential answers whether it changed since the camera or app signed it, and reading the EXIF fields on a laptop shows the software that last touched it. When the question turns from whether to when, use the guide to corroborating the creation date of a file.