Check a file with SHA-256, and understand what a match means

What SHA-256 calculates

SHA-256 transforms input bytes into a fixed-length digest. Its output contains 256 bits, commonly displayed as 64 hexadecimal characters. NIST includes SHA-256 in the SHA-2 family. A small text file and a large disk image therefore produce checksums with the same displayed length.

The calculation concerns the file’s contents, not its ordinary filename. Renaming an unchanged file does not change its digest. Editing data stored inside it, including embedded image metadata, can change the digest. This makes a checksum useful for comparing downloaded versions, copied archives or a file before and after a transfer.

Get the reference for the exact file

Use the software publisher’s official release page or verification instructions to find the expected SHA-256 value. Match the version, operating system, architecture and download variant. A checksum for a different release is not a useful reference even if the filenames look similar.

A secure connection to the correct publisher helps establish where the reference came from, but a raw checksum is not a digital signature. If someone can replace both a download and its displayed checksum, they can make the pair agree. Follow the publisher’s signed-verification procedure when one is available. Ubuntu’s instructions, for example, verify its signed checksum list before checking an installation image.

Calculate locally and compare the whole value

Select the downloaded file in the checksum tool and choose SHA-256 if the application offers several algorithms. Compare the full digest with the reference, not only its first or last few characters. Uppercase and lowercase hexadecimal letters represent the same value; missing or extra characters do not.

For a local alternative, PowerShell provides Get-FileHash, and Linux systems with GNU core utilities provide sha256sum. Substitute your actual file path in the examples. Quoting a path keeps spaces in a filename together. These commands read the file rather than running the installer.

A tiny example shows why bytes matter

A file containing exactly the three UTF-8 bytes for abc, without a newline, produces the digest shown below. A text editor that adds a newline creates different contents and therefore a different result. This is an example for understanding the calculation, not a reference checksum for any download.

The same issue can arise when comparing exported text. Two documents can look identical while differing in line endings, encoding or invisible characters. Check the intended file format and actual bytes instead of assuming a mismatch means the hashing application is unreliable.

Respond to a mismatch without guessing

A mismatch means the calculated digest does not equal the selected reference. First confirm the algorithm and release details, then check whether the download finished. An old release, incomplete transfer or accidentally edited file can explain a mismatch without establishing malicious activity.

For software, avoid running the mismatched copy while investigating. Obtain a fresh download and reference through the publisher’s documented route. If repeated downloads disagree, record the exact release and checksum information and consult that publisher’s support instructions rather than accepting the first plausible-looking file.

Know the limits before relying on a match

A match provides strong practical evidence that the selected bytes agree with the referenced digest. It does not scan for malicious code, prove a publisher’s identity, establish a file’s origin, or make an outdated application safe. Hash collisions are theoretically possible, so a fixed-length digest is not a mathematical promise that every possible file has a unique number.

A checksum also does not encrypt a file or conceal its contents. Treat it as one verification step alongside source authenticity and the publisher’s installation guidance. A file supplied by an unknown person does not become trustworthy simply because that same person supplies a matching hash.

Use a suitable tool for large files

Browser tools can calculate checksums locally, but the implementation determines whether data stays on the device. Read the tool’s processing statement. The Web Crypto digest API requires its complete input in memory, which can make large disk images impractical in a browser tab.

If the browser tool rejects the file size, stalls or reports insufficient memory, use a suitable local command-line utility. Keep the original file until the comparison is complete, and record the reference source beside the result when the check needs to be repeatable.

• Use the reference for the exact release and file.
• Compare the complete SHA-256 digest.
• Investigate mismatches before running software.
• Use signed verification when the publisher provides it.
• Remember that a checksum match is not a safety verdict.