A checksum is a value computed from data that lets you detect whether the data has changed. Think of it as a summary that is uniquely sensitive to any modification: if even one character in a file changes, the checksum changes completely. This makes checksums useful for verifying that a file you received is the same as the file that was sent.
The word ‘checksum’ comes from one of the simplest implementations: add up (sum) the numerical values of all the bytes in a piece of data, and use that sum to check whether the data arrived intact. Modern checksums are far more sophisticated, but the underlying idea is the same: compute a value from the data, and later verify the value still matches.
A Familiar Example: Check Digits
You encounter checksums in everyday life without thinking about them. The last digit of a credit card number is a checksum called a Luhn check digit. It is calculated from the other digits using a specific formula. When you type a credit card number into a payment form, the website verifies the Luhn check digit before even contacting the card network. If you mistype one digit, the Luhn calculation fails and the form tells you the number is invalid. The checksum detected the error.
ISBNs (book identification numbers) have a similar check digit. Barcodes on products have check digits. The last character of an IBAN (International Bank Account Number) is a checksum. None of these are security-critical cryptographic checksums, but they all use the same core idea: a value computed from the data that changes predictably when the data changes.
Three Levels of Checksums
Checksums range from simple mathematical operations to complex cryptographic functions. The level of sophistication determines what threats the checksum can detect.
Simple arithmetic checksums
The simplest checksums add up byte values, sometimes with modular arithmetic. These detect accidental single-bit errors and simple corruption. They cannot detect deliberate modification because it’s easy to change data and adjust the sum to match. Simple checksums are used in contexts where the threat is accidental error rather than intentional tampering: TCP/IP network packets, USB data transfer verification, and some embedded system communications.
CRC (Cyclic Redundancy Check)
CRC is a more sophisticated error detection algorithm widely used in storage and networking. CRC-32 is the checksum used inside ZIP files to verify archive integrity. It’s also used in Ethernet frames, Wi-Fi packets, and hard disk data verification. CRC is much more reliable than simple sums for detecting accidental corruption, including multi-bit errors. However, like simple checksums, CRC can be deliberately forged: someone determined to modify data and maintain the same CRC can do so with knowledge of the algorithm. CRC’s purpose is error detection for accidental corruption, not protection against deliberate tampering.
Cryptographic hash functions (MD5, SHA-256)
Cryptographic hash functions are designed to be resistant to deliberate forgery. SHA-256, for example, produces a 64-character string that changes completely if even one bit of the input changes, and has mathematical properties that make it computationally infeasible to create a fake file that produces the same SHA-256 as a legitimate file. When software publishers post SHA-256 checksums alongside downloads, they’re using a cryptographic checksum that provides meaningful assurance against both accidental corruption and deliberate modification.
MD5 is an older cryptographic hash that is now considered broken for security-sensitive purposes: researchers proved it’s possible to deliberately create two different files with the same MD5. For detecting accidental corruption in a download, MD5 still works. For security-critical purposes, SHA-256 or SHA-512 is the appropriate choice.
| Type | Example | Detects accidental corruption? | Detects deliberate modification? | Where you see it |
| Simple arithmetic checksum | Luhn check digit (credit cards), ISBN check digit | Yes, for simple errors | No: easy to forge | Credit card validation, barcodes, banking numbers |
| CRC (Cyclic Redundancy Check) | CRC-32 | Yes, very reliable for accidental errors | No: forgeable with knowledge of algorithm | ZIP files, Ethernet frames, hard drives, Wi-Fi |
| Cryptographic hash (MD5) | MD5 | Yes | Weakly: collision attacks possible | Legacy software downloads, some database integrity checks |
| Cryptographic hash (SHA-256) | SHA-256 | Yes | Yes: no practical attack known | Software downloads, code signing, TLS certificates, Git |
Why Checksums Matter for Software Downloads
When you download a file from the internet, the file travels through many network devices before reaching you. Any of these devices could introduce a corruption: a bit flip from electrical interference, a partial transfer that was silently resumed incorrectly, or a misconfigured caching layer that serves a stale version. These failures are rare but real, particularly for large files.
Software publishers who care about the integrity of their releases post checksums so that users can verify the download. If you compute the checksum of a 500MB installer and it matches the 64-character SHA-256 value on the publisher’s download page, you know those 500 million bytes arrived exactly as published.
Checksums also provide a layer of protection against supply chain attacks: if an attacker compromises a download mirror and replaces the legitimate software with a malicious version, the checksum will not match. Users who verify checksums will detect the substitution.
Checksums verify integrity, not safety. A checksum that matches tells you the file is identical to the reference. It doesn’t tell you whether the original file is free of malware, vulnerabilities, or unwanted behavior. A SHA-256 checksum match combined with a valid Authenticode digital signature from the expected publisher is a strong indicator that a file is what it claims to be. Neither alone is sufficient for complete assurance, but together they address the most common distribution integrity threats.
How to Verify a Checksum on Your Computer
Every major operating system includes built-in tools that compute checksums. No additional software is needed.
Windows
| # Windows PowerShell: compute SHA-256 checksum
> Get-FileHash C:\Downloads\Setup.exe -Algorithm SHA256 # Output: # Algorithm Hash Path # SHA256 A3B4C5…64 characters… Setup.exe
# Windows Command Prompt (older method): > certutil -hashfile C:\Downloads\Setup.exe SHA256
# Quick comparison (paste expected hash from download page): > (Get-FileHash C:\Downloads\Setup.exe).Hash -eq ‘paste-expected-hash-here’ # Returns: True (match) or False (mismatch) |
macOS and Linux
| # macOS: compute SHA-256
$ shasum -a 256 ~/Downloads/Setup.dmg
# macOS: compute MD5 (only if the download page provides MD5) $ md5 ~/Downloads/Setup.dmg
# Linux: compute SHA-256 $ sha256sum ~/Downloads/Setup.tar.gz
# Linux: verify against a .sha256 file (common in Linux distributions): $ sha256sum -c Setup.tar.gz.sha256 # Output: Setup.tar.gz: OK (if the hash matches) |
Checksum values from different operating system tools may appear in uppercase (Windows certutil) or lowercase (Linux/macOS sha256sum). A3B4C5 and a3b4c5 represent the same value. When comparing checksums, differences in case are not errors. Compare every character of the full hash string regardless of case.
What to Do If the Checksum Doesn’t Match
A checksum mismatch means the file you have is not identical to the file used to compute the reference checksum. Do not run or install the file until you have resolved the mismatch. The most common causes:
- Download was corrupted or incomplete: Delete the file and download again. Re-download from the original link, not a cached copy. After re-downloading, verify the checksum again.
- Downloaded the wrong file: Verify the filename matches exactly and that you downloaded for the correct platform (Windows vs macOS, 32-bit vs 64-bit).
- Wrong reference checksum: Some download pages list multiple checksums for different file versions or platforms. Confirm you are comparing against the checksum for your specific file.
- Download page or CDN is compromised: If re-downloading produces the same mismatching file, the download source itself may be serving a modified file. Look for an alternative official source (the developer’s GitHub releases page, a signed official mirror) and compare checksums from that source.
- The checksum on the page was updated without the file being updated: Rare, but possible if a publisher corrected a typo in the published checksum. Contact the publisher for clarification.
Checksums and Code Signing: Two Complementary Checks
Checksums and code signing certificates serve related but distinct purposes for software verification:
A checksum published by a software publisher tells you: this is the value I computed from the file I released. If your computed checksum matches mine, you have the same file. But the checksum is only as trustworthy as the channel through which you received the expected value. If the publisher’s website is compromised and an attacker replaces both the file and the posted checksum, the values will match and the file will still be malicious.
A code signing certificate (Authenticode signature) tells you: this file was produced by a specific verified organization, and has not been modified since it was signed. The signature is embedded in the file itself, not on a web page. Verifying the signature requires no external reference: the cryptographic proof is self-contained. This makes signature verification resistant to the website-compromise attack that checksums are vulnerable to.
Using both together: verify the checksum matches the published value (confirming the file matches the publisher’s release), and verify the Authenticode signature is valid with the expected publisher name (confirming the file was produced by a verified organization and hasn’t been tampered with). Each check catches threats the other might miss.
Frequently Asked Questions
What is the difference between a checksum and a hash?
The terms are often used interchangeably, but have a precise distinction. A checksum is any value computed from data that can detect whether the data changed. This includes simple sums, CRCs, and cryptographic hash functions. A hash (or cryptographic hash) is a specific type of checksum designed with security properties: one-way (cannot reverse it to get the original data), collision-resistant (cannot find two different inputs with the same hash). All cryptographic hashes are checksums, but not all checksums are cryptographic hashes. When software download pages list ‘SHA-256 checksum’ or ‘SHA-256 hash,’ they are using the terms interchangeably to refer to the same cryptographic value.
Is MD5 safe to use as a download checksum?
For detecting accidental file corruption during download, MD5 is still functional. The collision attacks that broke MD5 for cryptographic signature purposes require deliberate effort to construct: an attacker must carefully craft a malicious file to produce the same MD5 as a legitimate file. Accidental corruption from network errors does not produce constructed collisions. If a software publisher only provides an MD5 checksum, it still tells you whether the file arrived intact. For security-critical contexts, SHA-256 is the better choice, and some publishers provide both. When only MD5 is available, verify it rather than skipping verification entirely.
The download page doesn’t show a checksum. How else can I verify the file?
When no publisher-provided checksum is available, the primary verification tools are the Authenticode digital signature (right-click the file in Windows, Properties, Digital Signatures tab) and VirusTotal (upload the file at virustotal.com to scan with 70+ antivirus engines). The Authenticode signature verifies publisher identity and file integrity without requiring an external reference value. VirusTotal checks the file against known malware databases. Together these provide meaningful assurance even without a published checksum.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.