How to Verify a File Checksum on Any OS

Before calculating: identify four exact inputs

1. The artifact: confirm product version, operating system, CPU architecture, language, edition, and compression format.
2. The algorithm: record whether the publisher names SHA-256, SHA-512, SHA-1, or MD5. Digest values from different algorithms cannot be compared.
3. The expected digest: copy the complete value from a trustworthy page, signed manifest, package registry, or separate trusted communication.
4. The original file: verify the downloaded archive or installer before opening, extracting, converting, or resaving it.

Filenames are not globally unique. A mirror may reuse download.zip for several versions, and a browser may append (1) after a repeated download without changing the bytes. Verify the release metadata and expected size in addition to selecting the correct local file.

Verify a checksum in the browser

The LiveParse File Checksum Calculator reads a file you explicitly select, calculates its digest in the current tab, and can compare a pasted hexadecimal checksum. File contents are not sent to a checksum API. This is convenient on a device without a familiar terminal or for a moderate one-off file.

1. Open the calculator and choose the algorithm shown beside the publisher's value.
2. Select the exact local artifact with the file picker.
3. Paste only the complete expected hexadecimal checksum into the comparison field.
4. Wait for hashing to finish and confirm that the tool reports a full match.
5. Close the workflow without opening the file if it reports a mismatch.

Local browser processing reduces exposure to a remote conversion service, but browser extensions, endpoint monitoring, malware, and operating-system services remain separate trust boundaries. Use an approved device for confidential files. Native tools are often better for very large artifacts, repeated automation, or build pipelines.

Verify SHA-256 on Windows

PowerShell includes Get-FileHash. Open a PowerShell window, provide the exact path, and quote paths that contain spaces:

Get-FileHash -Algorithm SHA256 "C:\Users\you\Downloads\release.iso"

The output includes Algorithm, Hash, and Path. Compare the complete Hash value with the publisher's SHA-256 checksum. PowerShell commonly displays uppercase hex while a website may use lowercase; hexadecimal letter case does not change the bytes.

For a different supplied algorithm, use the exact supported name, such as SHA512, SHA1, or MD5. Do not switch to MD5 merely to get shorter output. The older Windows command certutil -hashfile "path" SHA256 can also calculate a hash, but PowerShell provides a clearer scripting interface.

Verify SHA-256 on macOS

macOS ships the shasum utility. Open Terminal and run:

shasum -a 256 "/Users/you/Downloads/release.dmg"

The command prints the 64-character digest followed by the file path. The -a 256 argument is important because the default is not a request for SHA-256. For SHA-512, use -a 512. Quote a path containing spaces or drag the file from Finder into the Terminal window after typing the command and a space.

If a publisher provides a checksum file in a compatible format, change into the download directory and use shasum -a 256 -c checksums.txt. Inspect which filenames the list references and verify the checksum file's own provenance before trusting a reported OK.

Verify SHA-256 on Linux

Many Linux distributions provide GNU coreutils sha256sum:

sha256sum "/home/you/Downloads/release.tar.xz"

Compare the complete first field with the expected SHA-256 value. Corresponding commands often include sha512sum, sha1sum, and md5sum, but available utilities depend on the distribution. Use SHA-1 or MD5 only when verifying an unavoidable legacy value.

For a compatible manifest, run sha256sum -c checksums.txt from the directory that contains the named files. A manifest can list many artifacts, so confirm that the expected row matches the downloaded architecture and version. A valid list format does not authenticate the list.

Compare the complete digest correctly

SHA-256 produces 64 hexadecimal characters. MD5 produces 32, SHA-1 produces 40, SHA-384 produces 96, and SHA-512 produces 128. A length mismatch usually means the wrong algorithm or an incomplete copied value. Spaces between byte pairs and uppercase letters can be presentation differences, but every hexadecimal digit must remain.

Do not compare only the first or last few characters by eye. A shortened prefix reduces the work needed to manufacture or accidentally encounter a matching display. Paste both full values into a trustworthy comparison field or use a checksum manifest command that parses the expected value and filename.

Be careful when checksum pages include labels such as SHA256 (release.iso) =. Those words are not digest characters. Conversely, do not accidentally copy a digest from the row above or below the intended architecture. Retain the source URL or signed manifest alongside audit records.

What to do when the checksum does not match

A mismatch means the selected bytes are not the bytes represented by the expected digest under the selected algorithm. Do not run an installer, mount an image, import a container, or bypass a package warning. Work through likely causes without assuming the difference is benign:

• Confirm the algorithm and expected digest length.
• Verify version, platform, architecture, locale, edition, and filename.
• Check whether the publisher hashed the archive while you selected an extracted file, or vice versa.
• Compare file size and look for an interrupted download or an HTML error page saved under the expected filename.
• Delete the suspect artifact and download a fresh copy through the official HTTPS route.
• Obtain the expected value again, preferably from signed metadata or an independent trusted source.
• If repeated official downloads disagree, stop and report the issue to the publisher.

Checksums verify equality, not publisher identity

SHA-256 is unkeyed. A person who modifies a program can calculate the modified program's SHA-256 checksum. If the same compromised website distributes both file and checksum, a perfect match only proves that the two malicious items agree.

A digital signature adds a private signing key and a public verification key. Signed release manifests let you authenticate many artifact names and hashes at once, provided you verify the signature, algorithm, and signing-key identity. Package managers may automate parts of this chain through signed repository metadata; do not disable those checks and replace them with a copied checksum.

The level of independent trust should follow risk. A checksum on the publisher's validated HTTPS page may be sufficient for detecting accidental mirror corruption in a low-risk workflow. Operating-system images, privileged software, firmware, and security tools justify stronger signature and key-verification steps.

Automate without weakening the decision

Continuous integration can download an artifact, calculate SHA-256, and fail closed on a mismatch. Pin the complete value in reviewed configuration, update it through code review, and record the artifact URL and version. Avoid scripts that scrape the newest checksum from the same mutable source immediately before accepting a download; that may let one compromise update both values.

Use a package manager's native signature and lockfile features when available. A lockfile checksum can make builds reproducible, but only if the lockfile itself is reviewed and protected. For internal pipelines, publish signed provenance or attestations and restrict who can update expected artifact digests.