Verify a SHA-256 checksum on Windows, macOS, and Linux

Short answer

To verify a SHA-256 checksum, hash the file with Get-FileHash on Windows, shasum -a 256 on macOS, or sha256sum on Linux. Compare all 64 hexadecimal characters with a checksum obtained from a trusted source. A match shows that the bytes agree with that reference; it does not by itself prove who published the file.

A reproducible text example

The ASCII text abc, with no trailing line ending, produces:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

The digest has 64 hexadecimal characters, or 256 bits. You can check the vector in the SHA-256 generator, which hashes UTF-8 text locally in the browser.

A space, capital letter, or line ending produces a different result. If a comparison fails, first verify the actual input bytes: copying text from a terminal or editor can add an invisible newline.

Verify a small file in the browser

For a file up to 20 MiB (20,971,520 bytes), open the SHA-256 file verifier, already in File mode, choose the download, and paste the trusted hash into Expected SHA-256. Press Calculate SHA-256 to read the original bytes locally and compare all 64 digits. Nothing is uploaded by the tool. Do not paste a binary file into Text mode.

Web Crypto needs the complete input in memory. For larger files, use one of the system commands below. A matching hash still does not prove the file is safe.

Verify SHA-256 on Windows with PowerShell

Open PowerShell in the folder containing the download and run:

Get-FileHash -LiteralPath '.\file.zip' -Algorithm SHA256

PowerShell prints the algorithm, the 64-character hash, and the path. The Get-FileHash documentation confirms that SHA-256 is the default, but specifying -Algorithm SHA256 keeps the command explicit and easy to audit.

Verify SHA-256 on macOS

Open Terminal, change to the directory containing the file, and run:

shasum -a 256 file.zip

The -a 256 option matters because plain shasum defaults to SHA-1. The shasum manual documents both the algorithm selection and its checksum-checking mode.

Verify SHA-256 on Linux

On a system with GNU coreutils, run:

sha256sum file.zip

GNU also documents cksum -a sha2 -l 256 file.zip as its newer general checksum interface. The familiar sha256sum remains a direct SHA-256 command; both are covered by the GNU Coreutils manual.

Check a SHA256SUMS file automatically

If the publisher provides a trusted SHA256SUMS file, sha256sum -c reads the expected hashes and filenames from it and checks the listed files. Do not pass the downloaded ZIP or ISO itself to -c: that option expects a checksum list, not the data to hash.

Run this from the directory containing the files named in the list. Replace the example directory with your download directory:

(cd '/path/to/downloads' && sha256sum -c SHA256SUMS)

On macOS, the equivalent using shasum is:

(cd '/path/to/downloads' && shasum -a 256 -c SHA256SUMS)

Why an absolute checksum-list path can still fail

sha256sum -c /path/to/downloads/SHA256SUMS locates the list, but does not change the working directory. A relative entry such as file.zip is resolved from your current directory, not from the directory containing SHA256SUMS. The parenthesized commands above change that directory only for the check.

An absolute filename inside the list is used as written; changing directory will not relocate it. Inspect the paths and use the publisher’s intended layout. Quote paths containing spaces in shell commands. Do not add shell quotes around filenames inside the checksum list: they would become part of the filename.

Reproduce a successful check with three bytes

In an empty test directory, create a file containing exactly abc, with no newline:

printf 'abc' > 'sample file.txt'

Save the following single line as SHA256SUMS, with two spaces between the hash and sample file.txt, and a newline at the end:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad  sample file.txt

Run sha256sum -c SHA256SUMS (or shasum -a 256 -c SHA256SUMS). The result is sample file.txt: OK. Adding a newline to the data file makes the comparison fail. This fixture demonstrates the procedure; generating a fresh hash from an untrusted download would not establish a trusted reference for that download.

Understand failures before retrying

• OK: this file matches its listed digest. Confirm that the list itself came from a trusted source.
• FAILED: the bytes do not match. Check the download version, completeness and expected hash; do not replace the expected hash just to pass.
• No such file or directory: a listed file could not be opened at that path. Check your working directory and the filename, including spaces.
• no properly formatted checksum lines found: the input is not a usable checksum list. Check for a bare hash without a filename, copied HTML or the wrong file.

For scripts, use the command’s exit status: 0 indicates success, and a nonzero status indicates failure. GNU --strict also makes malformed lines fail a check that otherwise contains valid entries. Avoid --ignore-missing for a complete download check, and do not treat one OK line as proof that every file passed. The GNU checksum options describe these controls. Diagnostic wording can vary by implementation and locale.

Compare the complete result

Compare all 64 characters without modifying the file. Letter case in the hexadecimal display does not change the value, but any different digit does. Do not compare only the beginning or end, and do not paste a binary file into a text hasher: text encoding or line-ending conversion would hash different bytes.

Integrity is not authenticity

SHA-256 is specified in NIST FIPS 180-4 and can detect changes when digests are compared. For the check to be useful, the expected hash must arrive through a trusted channel: an official HTTPS page, a verifiable digital signature, or an authenticated manifest.

If the file and checksum come from the same compromised location, the comparison only shows that they agree with each other. It does not identify the author or certify that the contents are safe.

Short procedure

1. Obtain the checksum from the official source and keep all 64 characters.
2. Calculate SHA-256 over the exact file without opening or converting it.
3. Compare the entire digest, not just its beginning or end.
4. If it differs, do not use the file; download it again from a known source and investigate.
5. If publisher identity matters, verify a digital signature as well.

This keeps two questions separate: “are these the same bytes?” and “can I trust who distributed them?”