What a checksum proves and what it does not

A hash function's one job

A hash function takes an input of any size; a word, a sentence, a multi-gigabyte file; and produces a fixed-length string of characters, deterministically: the same input always produces the exact same output, every time, on any computer. Feed it a different input, even one bit different, and the output looks completely unrelated to the previous one. That's the entire mechanism. A "checksum" is that output, used specifically to check that something matches.

Why one flipped bit changes everything

This is the property that makes a checksum useful at all: a well-designed hash function is built so that changing even a single bit of the input scrambles roughly half of the output bits, unpredictably. There's no "mostly the same" hash for "mostly the same" file; a one-byte difference and a completely rewritten file both produce outputs that look equally unrelated to the original. This is called the avalanche effect, and it's precisely why a matching hash is meaningful: there's essentially no way for corrupted or altered data to accidentally produce the same hash as the original.

Integrity is not authenticity

Matching values show that both inputs produced the same digest. With a collision-resistant algorithm such as SHA-256, that is extremely strong integrity evidence, but the hash must come through a trusted channel. If an attacker replaces both file and posted checksum, the comparison still passes. Digital signatures or authenticated distribution address provenance.

Why "broken" algorithms are still around

MD5 and SHA-1 have practical collision weaknesses and should not protect adversarial security decisions. They can still detect many accidental transmission errors, but modern algorithms such as SHA-256 are preferable when available and avoid ambiguity about the threat model.

Using checksum results responsibly

Two different files can theoretically share any fixed-length hash. With SHA-256 and no adversarial weakness, an accidental match is extraordinarily unlikely, not logically impossible.

Why do checksums look like random letters and numbers? They're a byte sequence (the raw output of the hash function) displayed in hexadecimal, since raw bytes aren't easy to read or copy-paste reliably as text.

Does a longer hash mean a more secure algorithm? Generally yes within the same algorithm family; SHA-512 has more output bits than SHA-256, making brute-force and collision attacks harder; but algorithm design matters more than length alone, which is why MD5's 128-bit output is weaker than SHA-1's 160-bit output by more than the length difference alone would suggest.

A checksum answers whether data matches a reference digest. Trust in the source requires that reference to be authenticated separately.