sha256sum — prove a file is the file it claims to be

$ sha256sum backup-2026-10-14.tar.gz
sha256sum -c SHA256SUMS

261edf25512c36ad24f3381a52140d6785283ccd40a96b0a8f859f27d99186e0  backup-2026-10-14.tar.gz
backup-2026-10-14.tar.gz: OK

The whole workflow in two commands, on a 51.2 MB archive I created on this box so the digest is real and reproducible from the bytes. The first line is the receipt: 64 hex characters, two spaces, the name — and those two spaces are digest, space, mode character, so a plain text-mode line always has an empty slot in the middle. The second command is the one people forget: -c does not take file names from the argument list, it reads them out of the checksum file, re-hashes each one, and prints OK only when it matches. Time this pair once and you will never skip it again: the hash of that 51.2 MB file took 0.115 seconds, about 445 MB/s, on a CPU whose flags include avx2 but no sha_ni.

$ sha256sum -c wrong.sums
sha256sum -c SHA256SUMS

backup-2026-10-14.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
backup-2026-10-14.tar.gz: OK
sha256sum: gone.bin: No such file or directory
gone.bin: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

Both halves of a real verification report, captured verbatim. The first is the outcome you are looking for the absence of: the digest in wrong.sums was 64 zeros, the computed one was not, so grep-style FAILED on the file line and a WARNING with the count on stderr — and the exit status is 1. The second is the nastier case, because the checksum list mentioned a file that is no longer on disk: you get the OS error, a verdict of 'FAILED open or read', and a separate warning that counts unreadable files rather than mismatched ones. That distinction matters when you are reading a report at 03:00 — a mismatch means corruption, an unreadable file means your list and your directory disagree about what should be there. Both exit 1, and so does a checksum file whose lines are garbage: 'no properly formatted checksum lines found'.

$ sha256sum -c --ignore-missing SHA256SUMS
sha256sum -c --quiet SHA256SUMS
echo "261edf25512c36ad24f3381a52140d6785283ccd40a96b0a8f859f27d99186e0  backup-2026-10-14.tar.gz" | sha256sum -c -

backup-2026-10-14.tar.gz: OK
sha256sum: gone.bin: No such file or directory
gone.bin: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read
backup-2026-10-14.tar.gz: OK

The three shapes you actually want in automation, all verified here. --ignore-missing is for the common case of a vendor manifest that lists a dozen files when you downloaded two: the absent entries are skipped silently and the exit status reflects only what was checked. --quiet inverts the report so stdout carries only the failures — perfect for cron, where a silent run means success and any line at all is the alert, though note that the missing-file diagnostics still go to stderr. The last one is the web-page case: a single hash copied out of a release note, pasted into a here-string with two spaces and piped into sha256sum -c -, which prints OK and exits 0. No temp file, no trust in the terminal's line wrapping.

$ find . -maxdepth 1 -name '*.bin' -type f -exec sha256sum {} + | sort -k2 | sha256sum

bf0419930ce4106d739069bba6b32e23a8730a7db98a43a781b364fee7f14f59  -

One digest for a whole set of files, and the pattern I use to prove a restored tree is identical to the original. The inner find batches every match into as few sha256sum processes as possible thanks to -exec ... {} + (the older \; form spawns one process per file and is dramatically slower on big trees), sort -k2 makes the manifest deterministic — directory traversal order is not something you should bet on — and the outer sha256sum collapses the whole manifest into a single line. Change one byte anywhere in the tree and this number changes. Two practical upgrades: use -print0 with xargs -0 when file names may contain spaces, and for huge trees throw xargs -P$(nproc) at it, because the hash of one file has nothing to do with the hash of another.

$ printf abc | sha256sum
sha256sum /dev/null
: > empty.txt; sha256sum empty.txt

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad  -
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /dev/null
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  empty.txt

The one-line answers that prove the implementation is doing what it says. 'abc' is the FIPS 180-2 test vector for SHA-256 and this build returns ba7816bf…15ad, exactly as published — which is also the fastest way to check that the sha256sum on some unfamiliar box is genuine and not a wrapper that returns something plausible. Hashing /dev/null returns the digest of zero bytes, e3b0c442…b855, and you will meet that same constant whenever a log rotation, a failed upload or a truncated backup produced an empty file: it is the fingerprint of nothing at all, and it is worth recognising on sight because it looks like a perfectly ordinary hash. Note the '-' in the first line — that is the file name field reporting the input came from stdin.

$ sha256sum "weird
name.txt"
sha256sum -z "weird
name.txt" | tr '\0' '|'

\2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881  weird\nname.txt
2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881  weird
name.txt|

What happens when a file name contains a newline, which it legally can and occasionally does. GNU detects it and defends the one-line-per-file promise by prefixing the whole record with a backslash and replacing the newline with the two literal characters \n — so the line stays one line and a parser can tell it is escaped (I confirmed both characters with cat -A). The -z form takes the opposite approach: it prints the raw name, newline and all, and ends each record with a NUL byte instead, which is why the tr in the pipeline shows the terminator as a pipe. If you are feeding checksums to a script, -z is the safer interface; if a human will read it, the escaped form is the one you want. Either way, this is exactly the behaviour coreutils 8.25 documented when it fixed the status output to a single line per file.