Was this file changed? What each check can show, and where it stops
A file cannot tell you on its own that it is the original. It can only be compared with something: a hash somebody published, the bytes a signature covers, the earlier versions it still carries, or the marks an edit tends to leave. Each of those answers a narrower question than the one you are asking, and a clean result from any of them is weaker than it looks.
Start with what you are comparing against. If somebody published a hash of the file, compare yours with it: identical hashes mean identical bytes. If the file is signed, find out exactly which bytes the signature covers, because a PDF signature can verify perfectly on a file that was added to afterwards. If there is nothing to compare with, the file's own history and the traces an edit leaves are what is left, and those can point you at where to look but cannot give a verdict either way. The guides below take each method in turn, with the checks that run in the browser tab and never upload the file.
Against a copy you trust: the hash
A SHA-256 hash reads every byte of a file and produces 64 hexadecimal characters, the same length for a six-byte file as for a six-gigabyte one, and a change to any byte changes the result beyond recognition. Two files with the same SHA-256 are, for every practical purpose, the same file. MD5 no longer carries that promise: pairs of different files with the same MD5 have been published, so a matching MD5 is not evidence that nobody tampered with a file on purpose.
The hash is only as good as the route the expected value took to reach you. A hash printed beside a download link on the same page as the file can be changed by whoever changed the file. How to check a file has not been changed covers where the value should come from and what a match does not tell you: not that the file is safe, and not when it was made. CHECKSUM does the comparison. When the file is one you received and may need to account for later, PROVENANCE records its SHA-256 with a note of where it came from, so the copy you examined can be shown later to be the copy you were given.
Against a signature: who, and how much of the file
A hash says two files match. It says nothing about who made either, since anyone can hash an altered file and publish the new value. A signature closes that gap by binding a digest to a private key, but each kind of signature covers something specific, and the gaps are where the trouble is.
A PDF signature covers a stated range of bytes, recorded as /ByteRange, and not necessarily the whole file. A PDF can be saved by appending, so anything added after signing sits outside the signed range and the signature still verifies. Was this PDF changed after it was signed? shows how to read the range against the file's real length. An S/MIME signature on an email, the smime.p7s attachment, covers the text and every attachment but not the From line, the recipients, the subject or the date; what smime.p7s is sets out what a valid one proves. For an ordinary email, SPF, DKIM and DMARC check the sending domain, and whether an email is really from who it says explains which of them is about the address a person actually sees. An SSH host key is checked by its fingerprint, and checking an SSH key fingerprint comes down to one rule: compare it with a fingerprint that reached you by another route, or it proves nothing.
Against the file's own history
Some formats keep what they used to be. Because a PDF can be saved by appending, a page deleted in most editors, a comment removed before the file went out and the text under a black rectangle drawn as a redaction can all still be inside the file, one version behind the one the reader shows. What a PDF keeps after you delete a page goes through what survives, and STRATA lists every version in the file and what changed between each pair.
A photograph keeps a different kind of history. Adobe's software writes an edit history into the XMP block; the file carries up to three times that answer different questions (when the shutter fired, when the file was last written, when the image was last changed); and the small thumbnail the camera wrote into the EXIF block is often left alone when the picture is cropped, so it can show what was cropped away. How to tell if a photo has been edited covers all three, and why the Software field that most advice points at is the weakest signal in the file.
Against the traces an edit leaves
With no reference and no history, the content itself is what is left. A cut in a recording is a join between two things that were never next to each other, and four traces tend to survive it: a step in the waveform, a change in the background noise, a jump in DC offset, and runs of exactly zero samples. Was this recording edited? explains each, and SPLICE measures them and gives timestamps to listen to. A photograph that claims a time can be checked against the sun: the length of a shadow against the height of what casts it gives the sun's elevation, its direction gives the bearing, and working out the time from a shadow shows how the pair narrows the day to one or two windows a claimed time either falls in or does not.
What none of them can do
Finding nothing is not evidence of nothing. The major social networks and most chat applications strip a photograph's metadata on upload, so a picture with no history is no more suspicious than any other. Anything that has been re-encoded as MP3, AAC or a voice note has lost the sample-level detail that shows a join in a recording. A Modified date later than the Created date means the file was saved again, which is true of nearly every document that has been through anybody's hands. Finding something is not proof either: a door closing makes a step in a waveform, and a phone muting itself makes a run of digital silence. The honest output of every method here is a shorter list of places to look, and the original file, in the state its device wrote it, is worth more than any analysis of a copy.
Making your own records show tampering
The same arithmetic works in the other direction, for records you keep. A log in which each entry is sealed with a SHA-256 taken over the seal of the entry before it forms a chain: change any entry and the seal at the head of the log changes. Write the head seal down somewhere else, and anybody can later check that nothing before it has moved. A decision log that shows tampering explains what such a log is examined for, and how a correction is made without hiding the original.
The single tools named on this page are free to open a file and see what they find; saving what they produce is part of Pro.
Every question under this one
- How to check a file has not been changedTake the SHA-256 of the file you have and compare it, character for character, with the value the publisher gave you.
- Was this PDF changed after it was signed?A signature covers a stated range of bytes, not the whole file, so anything appended afterwards leaves it verifying perfectly.
- What a PDF keeps after you delete a pageA PDF can be saved by appending, so the deleted page, the removed comment and the pre-redaction text are all still in the file and the reader just hides them.
- How to tell if a photo has been editedEverybody says check whether Software says Photoshop, which is the weakest signal in the file.
- Was this audio recording edited?Four traces a cut leaves behind and how to measure them without uploading the file, and why a lossy re-encode destroys all four, so finding nothing proves nothing.
- How to work out the time of day from a shadow in a photoThe ratio of a shadow to its object gives the sun's height and its direction gives the bearing, and both are computable for any place and date.
- Is an email really from who it says?Ignore the From line: it is text the sender typed, and nothing in delivery checks it.
- What the smime.p7s attachment on a signed email is, and how to check itIt is the email's signature, not a document. What is inside it, what a valid signature proves and what it does not, why mail programs call one invalid, and how to check it with OpenSSL or in a browser tab.
- How to check an SSH key fingerprint, and what to compare it withOne command prints it. The part that matters is comparing it with a fingerprint that reached you by another route, what the two SSH warnings are really telling you, and how to audit an authorized_keys file.
- What a decision log is examined forNobody is asked two years later whether a decision was right. They are asked what was known, what else was considered and when it was written down.
The same questions on the guides page, beside every other kind.