Change “blue” to “Blue,” and an apparently unrelated string of numbers appears.
The sentence barely changes. The fingerprint of its file changes dramatically. That contrast is the appeal of a cryptographic hash: you can compare a compact result instead of inspecting every byte yourself. But the comparison contains a quiet dependency. You need a reason to trust the fingerprint you are comparing against.
A checksum can confirm a match. It cannot introduce you to the sender.
What a file fingerprint is
SHA-256 takes bytes and produces a 256-bit digest, commonly written as 64 hexadecimal characters. The same bytes give the same result. A file name is not part of those contents: renaming a file alone does not change its content hash. Changing the stored bytes, even invisibly, ordinarily does.
The digest is not a compressed copy that can be expanded back into the file. Many possible inputs must share the finite space of outputs, so collisions exist in principle. For this purpose, SHA-256 is designed to make finding such collisions computationally infeasible. A match is strong practical evidence of matching contents, not a mathematical proof that every possible pair is identical.
A kettle, a capital letter, and some whitespace
We saved a harmless sentence, “The kettle is blue.”, followed by a line-feed newline. Its file contains 20 bytes. Then we made four versions: changing b to B, inserting one space before the newline, using a carriage-return plus line-feed ending, and removing the final newline. Each version was written to disk and read back.
Every edited file produced a different SHA-256 digest. The capitalization change actually flips just one bit of the input, but 120 of the 256 digest bits differ. The extra space changes 129 digest bits; the alternate line ending changes 128; removing the newline changes 125. Those are measured results for these particular files.
Whitespace is information to a hash
A reader may consider the two line-ending versions the same sentence. A byte-based comparison does not. Text editors, export tools, and transfers can change line endings or encodings without producing an obvious visual change. If a checksum fails, first confirm that you compared the same release and the exact file, rather than copied text or a regenerated version.
Do not read the number of differing digest bits as an edit-size score. The extra space did not make the document “more different” than the capital letter in any useful human sense. Hash outputs intentionally do not preserve that kind of resemblance. The patterns illustrate sensitivity, not a ruler for measuring meaning or damage.
A matching checksum can accompany the wrong file
Imagine receiving both a file and its expected checksum from one untrusted place. If someone replaces the file and calculates a new checksum for it, your comparison still passes. We demonstrated the arithmetic with the harmless capitalized sentence: pairing it with its own digest succeeds. No cryptographic weakness is needed; the reference itself has changed.
For a download, obtain the expected digest through a source you have good reason to trust, and compare all 64 hexadecimal characters using the same algorithm. A digest beside a download can catch accidental corruption. If the same compromised source can replace both, however, that pair alone cannot establish the publisher’s identity.
A signature adds a different kind of evidence
A digital signature can tie a file to a signing key and reveal changes after signing. The essential next question is whether the verification key really belongs to the publisher you intended. A valid signature under an unfamiliar key is not enough. Use the publisher’s documented verification process or a trusted distribution channel rather than improvising a trust chain.
Even a genuinely signed file is not guaranteed to be harmless, bug-free, current, or appropriate for your device. Integrity, authenticity, and safety are related but distinct checks. A checksum tool is not a malware scanner, and our text experiment did not test signatures, signing keys, executable files, or the security of any download service.
Keep the comparison attached to its context
Checksums are particularly useful when a file must survive a copy, transfer, or archive unchanged. Record the algorithm, exact file version, and a trusted reference digest together. If a later copy differs, pause and investigate rather than forcing the result to match or deciding immediately that an attack occurred.
If there is no trustworthy reference, a newly calculated hash still gives you a useful baseline for future comparisons. It does not retroactively prove where the current file came from. This modest distinction makes the tool more useful: you know which uncertainty it removes, and which questions are still yours to ask.
Further reading
NIST: Secure Hash Standard, FIPS 180-4 ↗Python: hashlib ↗NIST: Digital Signature Standard, FIPS 186-5 ↗Original documentation and useful background.