Checksums and Data Integrity: Knowing a File Hasn't Changed

When you download a large file, a Linux ISO, a software release, a database export, there is a question that is easy to ask and slightly harder to answer: is the file on disk byte-for-byte the file the publisher intended to send? Networks corrupt packets, mirrors get tampered with, and downloads sometimes silently truncate. A checksum is the cheap, standard answer: a short fingerprint computed from the file's contents that changes if even a single bit of the file does.

What a hash actually proves

A cryptographic hash function takes an arbitrary input and produces a fixed-length output, called the digest or checksum. The same input always produces the same digest; a different input produces a different one. That is the whole property that makes integrity checks work: you compute the digest of the file you received, compare it against the digest the publisher published, and if they match, the file is almost certainly byte-identical to what was published.

The "almost certainly" is worth being precise about. For a strong hash with a 256-bit output, the chance that two different files share a digest by accident is astronomically small, small enough to ignore for any practical purpose. What the match proves is that the contents have not changed. What it does not prove is who published the file, which is a separate problem that requires digital signatures rather than bare hashes.

Computing a digest locally is a one-liner on every common platform:

# macOS / BSD
shasum -a 256 release.zip

# GNU coreutils (most Linux)
sha256sum release.zip

# OpenSSL, anywhere it is installed
openssl dgst -sha256 release.zip

The output is a hex string followed by the filename. Compare it to the value the publisher published, character by character, or with a tool that does the comparison for you. Any difference, no matter how small, means the file is not the same.

Picking an algorithm

Not all hash functions are equal, and the choice matters because older ones are no longer safe. MD5 and SHA-1 are broken for integrity against an active attacker. Collisions, two distinct inputs that produce the same digest, can be generated for both, which means a tampered file can be crafted to match a known good checksum. For casual, non-adversarial corruption checks they still detect random bit rot, but they should not be used for anything that has to resist deliberate tampering.

Algorithm  Output     Status
MD5        128-bit    broken, collision-feasible
SHA-1      160-bit    broken, collision-feasible
SHA-256    256-bit    current standard, recommended
SHA-512    512-bit    current, fine for larger files
BLAKE2/3   variable   modern, fast, recommended where available

For download verification and tamper detection today, SHA-256 is the default and what most publishers publish. The hash generator tool computes several of these in the browser without uploading the file, which is convenient for checking small files against a published value.

Where the comparison gets used

The download check is the most visible case, but the same idea shows up across engineering.

• Release artifacts. A project publishes a tarball and its SHA-256 alongside it; the installer script recomputes the digest and refuses to proceed on a mismatch, so a tampered mirror cannot push a backdoored build.
• Backups. A backup tool records the digest of each file when it is written and checks it again on restore, catching silent corruption from disk errors, bit rot, or failing hardware that would otherwise surface as missing data months later.
• Configuration and data files. Pipeline steps hash their inputs so a later stage can tell whether anything upstream actually changed, skipping expensive reprocessing when nothing did. For structured data like JSON, a structured diff is usually more useful than a raw hash; the JSON compare tool shows exactly which fields differ rather than just "the file changed."
• Reproducible builds. The same source and the same toolchain should produce a binary with the same digest. If they do not, something in the environment differed, which is a signal worth investigating.

Try it: Hash Generator

Compute SHA-1, SHA-256, SHA-384, and SHA-512 hashes of any text.

Hashes are not signatures

The distinction that catches people is between integrity and authenticity. A matching hash tells you the file has not changed since the hash was computed. It does not tell you who computed it. If an attacker can replace the file, they can usually replace the published hash next to it as well, so a bare checksum on a download page protects against corruption and casual tampering but not against a determined attacker who controls the page.

For authenticity you need a signature. The publisher signs the digest with a private key, and you verify it with their published public key (GPG, minisign, Sigstore, or a platform's code-signing certificate). Signatures build on hashes; they do not replace them. The hash answers "did this file change," and the signature answers "was the change made by the right person." For verifying a Linux ISO you want both. For noticing that your nightly export stopped truncating halfway through, the hash alone is enough.