How to Verify a File with a Checksum: SHA-256 and SHA-512 in Practice

A multi-gigabyte system image reached 99 percent and the connection dropped, and now you cannot tell whether the file arrived intact or the last megabyte turned into zeros. Or the installer came from a mirror, and you would like to know that what landed on your disk is exactly what the publisher uploaded, not something a middleman slipped in on the way. Both questions are answered by the same short procedure: compute the checksum of the file and compare it against the one the publisher posted. It takes a minute, and nothing needs to be installed, because Windows, Linux and macOS all ship the tools already. This article walks through the procedure step by step, explains mismatches, and covers why downloads get verified with SHA-256 rather than MD5.

What a checksum proves

A checksum is a fingerprint of the file computed by a hash function. The fingerprint has two defining properties. First, the length is always the same: SHA-256 of anything, a two-megabyte file or a forty-gigabyte one, is a string of 64 hexadecimal characters. Second, the fingerprint is bound to the content: flipping a single byte in the middle of the file changes the whole sum, and there is no way to predict how it changes. Where these properties come from is covered in the article about MD5 and SHA-256 hashes; here we focus on the procedure itself.

Set the boundaries right away. Against a dropped connection and a corrupted download, verification is reliable: a file that arrived with an error will almost certainly fail the check. Against deliberate tampering it works under a single condition: the checksum must come from a place independent of the file itself. That is not a formality but the main rule of the whole procedure, and we return to it in the section about mismatches.

Where publishers post checksums

Look for the sum next to the file, usually in the same places as the download itself:

• on the download page next to the download button, often in small print or inside a collapsible technical-details block;
• as a separate file in the same directory: next to disk-image.iso there is disk-image.iso.sha256, or a SHA256SUMS file listing every sum of the release;
• on the GitHub release page: sums are published in the release notes or attached as a file to the asset list;
• in documentation or in a message, when the file is shared individually: the sum travels separately from the file.

The file extension hints at the algorithm: .sha256 means SHA-256, .sha512 means SHA-512, .md5 means MD5. A file with a .sig or .asc extension is a different animal: that is a cryptographic signature verified with the publisher public key, a stronger scheme with its own setup. The idea behind signatures is explained plainly in the article about HMAC and request signing; for ordinary download checks a checksum is enough.

Computing the sum: Windows, Linux and macOS

Windows: certutil with nothing to install

Windows has shipped the certutil utility for years, and the -hashfile option has been available since Windows 7. Open an ordinary command prompt, no administrator rights required, and run:

certutil -hashfile C:\Users\you\Downloads\disk-image.iso SHA256

// output on an English Windows:
SHA256 hash of C:\Users\you\Downloads\disk-image.iso:
f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310
CertUtil: -hashfile command completed successfully.

One line matters, the second from the top: 64 hexadecimal characters right after the SHA256 header. Some older certutil versions print the hash in two-character groups separated by spaces; strip the spaces before comparing. The line about successful completion carries no information and is ignored.

The second built-in option is PowerShell: Get-FileHash does the same job and prints the sum in uppercase. Case makes no difference: F0A72CDC and f0a72cdc are the same sum, hexadecimal characters compare case-insensitively. Normalise both strings before comparing and the difference in spelling stops being confusing.

Linux and macOS: sha256sum and shasum

On Linux, sha256sum is part of coreutils and present in every distribution. On macOS the counterpart is shasum with an algorithm flag:

$ sha256sum checksum-demo.txt
f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310  checksum-demo.txt

$ shasum -a 256 checksum-demo.txt     # macOS
f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310  checksum-demo.txt

The output has two parts: the sum on the left, the file name on the right, two spaces between them. The format is not an accident: it matches the SHA256SUMS file format, which is why the automatic check in the next section works without any conversion. For SHA-512 the commands change suffix: sha512sum or shasum -a 512.

Comparing: by eye or by machine

The manual way: copy the sum from the publisher page and the computed sum into adjacent lines of any editor and compare. The trouble is that 64 characters are tiring to compare by eye, and mistakes are cheap: the first twenty characters matched, the eye relaxed, and nobody noticed the difference hiding in the tail. If you compare manually, stack the lines on top of each other in an editor with difference highlighting.

A machine does it better, and a ready format already exists. The publisher ships a SHA256SUMS file where every line is a sum, two spaces and a file name. Put that file into the downloads directory and run a single command:

$ cat SHA256SUMS
f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310  checksum-demo.txt

$ sha256sum -c SHA256SUMS
checksum-demo.txt: OK

# and if the file on disk is damaged:
checksum-demo.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

The command recomputes every sum in the list and prints a verdict next to each file. Any FAILED line means the content differs from what the published sum was computed over. Watch for one common trap: the file name inside SHA256SUMS must match the name on disk down to letter case, otherwise the tool reports the file as missing, which is a different verdict than a mismatched sum.

A worked example you can repeat

Take a small text file called checksum-demo.txt so the whole procedure fits into a minute and you can see with your own eyes what damage looks like. The file holds three lines, Unix-style line breaks and a trailing newline; sixty bytes in total:

ToolBox Pro checksum demo file
version 1.0
all bytes intact

SHA-256 = f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310
SHA-512 = 4194d2873450f9d13dfae599626c6f96a59cfa3b30447cb7fcb1df4ad7ba9e09743cd0c0cdc2a4d330a97a4de6d7f9fac24b65467c5579d6e9824dc2da85203a
MD5     = 0e85fcf22e3f2a4a3685bc7513e2fe5a

Recreate the file with this content in any editor and compute the sum with one of the commands above. Notice that the hash depends on bytes, not on visible text: save the file with Windows line breaks (CRLF) or without the trailing newline, and the sums change while the text on screen stays identical. That is not a defect of the algorithm but its exact behaviour: it answers for the bytes it was given.

Now simulate damage: change 1.0 to 1.1 in the middle line, exactly one byte. The new SHA-256 reads 4c2284d24ada49e88d696a3b96d83aeaaf513ee5abe300d6e133ccea5c752080. No recognizable fragment of the old sum survives, and predicting which positions change and how is impossible. A real image cut off mid-download differs in thousands of bytes rather than one, but the conclusion is the same: the check catches the damage every time.

What SHA-512 changes in the procedure

Nothing, apart from the algorithm name and the string length. SHA-512 produces 128 hexadecimal characters instead of 64, and on modern 64-bit processors it is often computed faster, because the algorithm works with 64-bit words. The commands are familiar with a new name: certutil -hashfile file SHA512, sha512sum file, shasum -a 512 file.

Publishers often post both sums side by side, and newcomers wonder which one to check. The answer: either, as long as you hold a published value for it. You cannot compute SHA-256 locally and compare it with SHA-512 on the page: different lengths, different algorithms. And neither sum is a backup for the other: both were computed over the same file, and both must match.

Why MD5 and CRC32 fall short for downloads

Both older sums solve the problem of a file damaged in transit, not the problem of a file replaced on purpose, and the mechanisms differ:

• CRC32 is a 32-bit sum from the data-link world: it was designed to catch random transmission errors, where a one-in-four-billion chance of missing damage sounds acceptable. For an attacker, crafting a second file with the same CRC32 is trivial, and 32 bits are brute-forced in seconds on ordinary hardware;
• MD5 is stronger than CRC32 yet still deliberately broken: pairs of different files with identical MD5 sums can be crafted on demand, and history has confirmed the risk. In 2012 the Flame malware forged a Microsoft code-signing certificate using a constructed MD5 collision;
• SHA-256 has no practical collisions today and remains the standard for verifying downloads; SHA-512 offers the same trust with a longer output.

If the publisher posts only MD5, checking is still worthwhile: against an accidental corrupted download the old sum works fine, and constructed collisions do not mimic random damage. Keep the boundary in mind, though: MD5 will not notice a deliberate swap of the file together with the sum, so for critical downloads look for a source that posts SHA-256 or a signature.

When the sums do not match

A mismatch is not a verdict on the file but a signal to investigate. Work through the list:

1. do not run the file until the cause is clear: the content differs from what the publisher posted, for whatever reason;
2. download the file again, preferably from a different mirror or straight from the official server, and recompute the sum: one flaky connection explains most real-world mismatches;
3. check you are comparing the right file: releases with similar names have versions and architectures, and the sum for an amd64 image will not match an arm64 file;
4. check you did not hash the wrong object: the text file listing the sums instead of the image, the download page itself, a wrapper archive. In a terminal this looks like passing certutil a path to a page rather than to a file;
5. check the algorithm: a SHA-1 sum next to an expected SHA-256 will never match, although both look like long hex strings;
6. if the mismatch repeats against the official source, report it to the publisher: the page may still carry the sum of a previous file version.

Common mistakes

• comparing against a foreign line from the list: a release carries a dozen sums for different files, and a sum taken from the wrong row fails on a perfectly intact file;
• copying the sum together with a stray space or a line break: the string comparison honestly reports a mismatch, and the person re-downloads a healthy file;
• hashing the sums file instead of the image: SHA256SUMS is a file too, with a sum of its own;
• checking MD5 from an outdated instruction after the project moved to SHA-256, and wrongly concluding the download is corrupt;
• trusting the sum from the same mirror the file came from: a compromised mirror swaps both the file and the sum next to it, and the check passes without a complaint;
• eyeballing the first ten characters: a short fragment proves little, and the difference can hide at the end of the string.

Frequently asked questions

Can an online hash calculator replace the command line?

For text and small text files, yes: the SHA-256 generator and the SHA-512 generator compute everything in the browser and accept a file upload as long as it is text. Gigabyte-sized images and binary archives are not something a browser tool should hash, which is what certutil and sha256sum are for. When the publisher posted several sums at once, paste the content into the multi-hash tool once and get every algorithm side by side.

The sums match, so is the file trustworthy?

A match proves that the content on disk is the same as when the sum was published, and that the download did not break on the way. But if the sum came from the same compromised resource as the file, tampering is not excluded: an attacker changes both objects. Real confidence appears when the sum or the signature comes from an independent place: the project official site or a signed release.

Why verify at all if the sum sits next to the file on the same server?

Checking against the same server still catches broken downloads: dropped connections, disk errors, misbehaving proxies. It does not protect against the ill intent of the server owner, and the honest answer is that tamper protection needs a signature verified with the publisher public key, or a sum from an independent channel. The practical rule: take the file from anywhere, take the sum only from the official page.

The publisher posts only MD5. What now?

Verify the MD5 anyway: against accidental corruption it is perfectly reliable, and constructed collisions are crafted on purpose rather than mimicking random damage. The boundary stays the same: MD5 will not detect a deliberate swap. If the file is critical, look for the same release in a source offering SHA-256 or a signature: large projects usually publish sums in several formats at once.

Why does an empty file have a checksum?

The hash function is defined for any input, including zero length: SHA-256 of an empty file is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, a constant identical on every system. This gives you a handy sanity check: if your command suddenly produces this constant, you hashed the wrong object or the file turned out to be empty.