Checksums explained: how to verify a downloaded file

A checksum is a short fingerprint computed from a file’s contents. Feed the same bytes in, get the same fingerprint out, every time, on any machine. Change one byte anywhere in a gigabyte and the fingerprint changes completely. That single property - contents in, stable fingerprint out - is what makes verification, deduplication and integrity checking work, and using it takes about thirty seconds once you know the commands.

What a checksum tells you, exactly

Two files with the same checksum have the same contents, regardless of their names, dates or where they live - which is why duplicate finders are checksum tools at heart. Two files with different checksums differ somewhere, even if they open identically and nothing looks wrong.

What a checksum does not tell you is which copy is correct. It proves sameness or difference against a reference; the reference has to come from somewhere you trust - the publisher’s stated hash, or the source file you copied from.

MD5, SHA-256 and which to use

You will meet two families in the wild. MD5 is old and fast, and its weakness is specific: a determined party can construct two different files sharing an MD5. Against accidents - corruption, truncation, a flaky transfer - it remains perfectly serviceable, which is why storage systems still use it internally. SHA-256 has no known way to engineer collisions, so it is the right choice whenever a person might be the problem rather than a wire: verifying software, confirming nothing was tampered with in motion.

The rule of thumb: integrity against mistakes, either works; integrity against people, SHA-256.

Computing one, per platform

Every platform ships the tools:

macOS and Linux:

shasum -a 256 backup.zip
sha256sum backup.zip

(the first on macOS, the second on most Linux distributions)

Windows, PowerShell:

Get-FileHash backup.zip

which prints SHA-256 by default. Compare the output against the reference - matching the first and last handful of characters by eye is the practical standard, since a mismatch anywhere scrambles the whole string.

When verifying is worth it

Downloaded software and disk images. Publishers list hashes precisely so you can confirm the artefact that arrived is the artefact they shipped. Thirty seconds, and the only cost of skipping it appears at the worst time.

Backups you will need to trust later. A backup is a hope until tested; hashing a sample after the copy is the lightweight version of that test.

Any large transfer where “it probably worked” is not enough. Multi-part archives, big uploads that resumed, files that crossed several hands on the way to you.

Letting tools do it continuously

Hand-checking one file is fine; hand-checking a nightly backup is not a workflow. Transfer tooling builds the verification in: rclone compares checksums as it copies against our S3-compatible API, and

rclone check ~/Documents dosya:backup/documents

audits an existing copy end to end, reporting any file whose fingerprint disagrees - which turns “I assume the backup is fine” into a command with an exit code. The rclone docs cover the setup.

One caveat for S3 users generally: the ETag a bucket reports is only a plain MD5 for single-part uploads; large files uploaded in multiple parts carry a composite value instead. Comparing ETags by hand on big files therefore misleads - let rclone check do the comparison properly rather than eyeballing dashboard values.

The habit, compressed

Publisher gives a hash: check it. Backup finishes: rclone check it, or hash a sample. Two files might be the same: hash both and know. It is the rare security habit that costs seconds, requires no judgement, and gives a yes-or-no answer every single time.