What a hash is
A cryptographic hash reduces any amount of data to a fixed-length fingerprint. Two properties make it useful: the same input always gives the same output, and finding a different input with the same output should be computationally infeasible.
The first property is what you use when you compare a download against a published SHA-256. The second is what makes that comparison mean anything.
Before you read on
You download a file and its SHA-256 matches the one published on the same page. What has that proved?
That the bytes you have are the bytes that produced the published digest — nothing added, nothing lost, nothing corrupted in transit. It proves nothing about safety, and it only proves the absence of tampering if the hash itself came from somewhere an attacker could not reach. A hash published beside its own download is protected by exactly as much as that page is.
The three claims, in order of strength
“These bytes are those bytes.” True, and this is the whole of what a hash gives you. A match means the file is bit-for-bit what produced the published digest.
“This file was not tampered with.” True only if the hash itself is trustworthy. A hash published on the same page as the file it describes is protected by exactly as much as that page is: an attacker who can swap the download can usually swap the digest beside it. The value of a checksum comes from where it came from.
“This file is safe.” Not established at all. Malware has a valid checksum. Integrity and safety are unrelated questions, and conflating them is the most common misunderstanding here.
Why the hash differs when the file “is the same”
A hash has no tolerance whatsoever. One bit changes every subsequent bit of the output — the avalanche property, which is deliberate.
So when a file that looks identical hashes differently, something about the bytes really did change. Usually one of:
- Line endings. A text file saved on Windows carries a carriage return before every newline. Same words, different bytes.
- A trailing newline. Some editors add one on save; some do not.
- A byte-order mark. Three invisible bytes at the front of a UTF-8 file.
- A partial download. Truncated files hash perfectly and match nothing.
- Metadata. Re-saving an image or an audio file can rewrite a timestamp or a tag while leaving the content untouched.
None of these is a bug in the hash. Each is the hash telling you something you could not otherwise see.
The distinction becomes especially clear after a lossless edit. When you trim a WAV file without re-encoding it, the retained sample bytes can be copied exactly while the complete file gets a different digest. The RIFF length, data length and physical set of bytes have changed; metadata may have been removed; and the audio now begins at a different frame. “The kept samples are unchanged” and “the two files are identical” are different claims, and only the second one would produce a matching checksum.
SHA-1 is a legacy format now
SHA-1 was broken in practice in 2017, when two different PDF files with the same SHA-1 digest were published. The attack has only become cheaper.
It survives because a great deal of infrastructure emits it, and because detecting accidental corruption does not require collision resistance. That is the honest use: comparing against something old that publishes nothing better. For anything where an adversary might be involved, SHA-256.
Reading what a file says about itself
A related but distinct question: not “are these the right bytes” but “what do these bytes claim to be”.
Every media format carries a header describing what follows — sample rate, channel count, bit depth, duration, codec. Reading it means parsing a few dozen bytes rather than decoding the content, which is why it is instant even on a large file.
Two things worth knowing:
The extension is a claim, not a fact. A file named .wav can contain
anything. Sniffing the leading bytes is the only way to know what a file
actually is, which is why the tools here identify formats from content rather
than from names.
A header can disagree with the content. A declared duration is metadata, and a truncated or badly written file can advertise one length while containing another. A header tells you what the file says about itself, and that is a genuinely useful thing to know — including when it turns out to be a lie.
Common questions
What does a matching checksum actually prove?
That the bytes you have are exactly the bytes that produced the published hash — nothing added, nothing lost, nothing corrupted in transit. It proves nothing about whether those bytes are safe, or about who made them. A malicious file has a perfectly valid checksum too.
Is SHA-1 still safe to use?
Not for anything security-related. A practical collision was demonstrated in 2017 — two different PDFs with the same SHA-1 — and the cost of producing one has fallen since. It remains useful for detecting accidental corruption and for matching against legacy systems that publish nothing else, which is the only reason to compute it today.
Why does the same file give a different hash?
Because something about the bytes differs, and the usual culprits are invisible: a text file saved with Windows line endings against Unix ones, a trailing newline, a byte-order mark, or a partial download. A hash has no tolerance at all — one bit changes the entire output, which is the property that makes it useful.
Can I trust a checksum published on the same page as the download?
Only against accidents. If an attacker can replace the file they can usually replace the hash beside it, so the pair proves the download did not corrupt in transit and little more. A hash is worth much more when it comes from a different channel — a signed release, a separate domain, a package manager's own index.