The Complete Guide to File Integrity Checks

A file integrity check is the simplest, cheapest insurance in computing: a quick way to prove that a file is exactly what it should be — bit for bit — whether it just finished downloading, sat in a backup for three years, or was copied across a flaky network. This guide explains what integrity checks are, how to run them on any platform, which algorithm to pick, and the practices that separate a real guarantee from a false sense of security.

What is a file integrity check?

A file integrity check works by computing a cryptographic hash — a short, fixed-size fingerprint — of a file’s contents, then comparing it against a known-good value. If the two match, the file is intact. If even a single byte differs, the fingerprints will look nothing alike, and you know the file changed.

That fingerprint is called a checksum, hash or digest. The same input always produces the same digest, so two people on opposite sides of the world can independently confirm they hold an identical file.

Why file integrity matters

• Downloads can be silently corrupted in transit, or deliberately replaced on a compromised mirror. A checksum catches both.
• Backups and archives suffer bit rot — slow, silent corruption on disks and tapes over time. Re-hashing detects it before you need the data.
• Deployments must ship the exact artifact that was built and tested, not a truncated or swapped copy.
• Forensics and compliance depend on being able to prove that evidence or records were never altered.

How it works, step by step

1. The publisher computes the hash of the original file.
2. They publish that hash next to the download (often in a SHA256SUMS file covering many files at once).
3. You download the file.
4. You compute the hash of your copy.
5. You compare the two values. Match = intact; mismatch = corrupted or tampered.

Choosing a hash algorithm

Not every algorithm is appropriate for every job. The key question is whether you only need to catch accidental corruption, or also defend against a deliberate attacker.

Algorithm	Good for	Notes
CRC-32	Accidental corruption only	Fast, tiny, but not cryptographic — never for tamper detection
MD5 / SHA-1	Legacy / non-adversarial checks	Broken against deliberate collisions — avoid for security
SHA-256	The default choice	Secure baseline for tamper-evident integrity
SHA-512 / BLAKE3	Large files, high throughput	Secure and often faster on modern 64-bit hardware

For anything that must resist tampering, use SHA-256 or stronger. If you want the full story on why the older functions fell, see our companion article, Understanding SHA-256: Why It Matters.

Computing checksums on every platform

Every major operating system can do this out of the box:

# Linux — hash a file, then verify against a checksum file
sha256sum file.zip
sha256sum -c SHA256SUMS

# macOS
shasum -a 256 file.zip

# Windows (PowerShell)
Get-FileHash file.zip -Algorithm SHA256

# Windows (Command Prompt)
certutil -hashfile file.zip SHA256

The SHA256SUMS approach scales nicely: one text file lists the expected hash for every file in a release, and sha256sum -c verifies them all in a single command.

Verifying a download the right way

Computing a hash is only half the job — where you get the expected value is what makes the check trustworthy.

• Get the expected hash from an independent, trusted channel. If you download the file and the checksum from the same compromised mirror, an attacker simply swaps both. Fetch the checksum over HTTPS from the official site.
• Prefer signed checksums. Many projects publish a SHA256SUMS file with a GPG signature. Verifying the signature proves the checksum list itself is authentic — not just internally consistent.
• Compare the whole string. Don’t eyeball only the first and last few characters; let a tool compare the full digest.

Beyond downloads: where integrity checks pay off

• Backups & archives. Store a checksum manifest alongside each archive and re-verify it periodically to catch bit rot before a restore fails.
• File transfers. After a large SFTP/FTP copy or a move between drives, hash both ends to confirm nothing was truncated.
• Deployment artifacts. Pin the expected hash of a build artifact and verify it in your pipeline so only the tested binary ships.
• Forensics & recovery. Hash evidence to prove it was untouched — and verify that files reconstructed during recovery came back whole.

Integrity vs authenticity vs confidentiality

These three are easy to conflate but solve different problems:

• Integrity — the file has not changed. A plain checksum gives you this against accidental corruption.
• Authenticity — the file genuinely comes from who you think. This needs a digital signature or HMAC, because a determined attacker could otherwise alter both the file and its checksum.
• Confidentiality — the file stays secret. That is the job of encryption, not hashing.

In short: a bare checksum proves integrity; pair it with a signature when you also need to trust the source.

Best-practice checklist

• Use SHA-256 or stronger for anything security-relevant.
• Always obtain the expected hash from a trusted, independent source.
• Verify after downloads, transfers, and restores — not just once at creation.
• For many files, use a checksum manifest (e.g. SHA256SUMS) and verify in one pass.
• Prefer signed checksums when the source could be attacked.
• Automate integrity checks in backups and deployment pipelines so they actually happen.

Key takeaways

File integrity checks turn “I think this file is fine” into “I can prove it.” They cost milliseconds, work on every platform, and catch everything from a dropped packet to a malicious swap. Pick a strong algorithm, verify against a trusted value, and bake the habit into your downloads, backups and deployments — and a whole class of silent failures simply stops being able to hurt you.