What Is a Checksum? How to Verify Files and Investigate Errors

Key takeaways

• A checksum compares data with an expected value; a mismatch identifies a difference without explaining its cause.
• Simple error-detection checksums and cryptographic hashes offer different protection against deliberate manipulation.
• Verification must use the correct file, release, algorithm, and complete reference value.
• A matching hash does not establish publisher identity or software safety when the reference itself is untrusted.

A checksum is a value calculated from data and used to help detect changes. A sender can calculate it before distributing a file, and a recipient can calculate it again from the received bytes. Comparing the values provides evidence about whether those bytes match the expected content.

Suppose you download an installation image and its publisher supplies a SHA-256 value. The download completing tells you that the browser finished its transfer. Comparing the file’s hash with the publisher’s trusted reference answers a more specific question: does this copy correspond to the expected image?

The comparison is useful because a filename and file size cannot establish that every byte is correct. It also has limits that matter when interpreting the result.

How a Checksum Works

A checksum algorithm processes input and produces a compact result. Applying the same algorithm, with the same parameters, to the same bytes produces the same value.

An intentionally simple example adds the ASCII values of three letters:

CAT: 67 + 65 + 84 = 216
CAR: 67 + 65 + 82 = 214

The changed letter produces a different sum. But rearranging the original letters into ACT still produces 216. The example detects some changes and misses others.

Two different inputs producing the same result is called a collision. Fixed-size checksum outputs have a limited number of possible values, while files can contain vastly more possible inputs. A match therefore needs to be interpreted in the context of the algorithm and the kind of change being considered.

Checksums and Cryptographic Hashes

The word checksum is often used broadly for a file-verification value, including a cryptographic hash. It is useful to distinguish that role from the properties of the algorithm.

Algorithms such as CRC32 are designed for efficient error detection. They are not intended to stop an attacker deliberately constructing data that passes the check. Cryptographic hashes such as SHA-256 are designed to make finding relevant collisions or matching alternative inputs computationally difficult.

Microsoft’s file-hashing documentation identifies SHA-256 as the default for PowerShell and cautions against using MD5 or SHA-1 where protection against tampering is required. An old MD5 manifest can still help identify accidental differences, but it should not be treated as equivalent to a modern cryptographic verification scheme.

The comparison must use the algorithm the reference specifies. Calculating SHA-256 does not let you compare directly with a published MD5 value.

What Bytes Are Being Checked?

A file hash normally covers the file contents, not its name or folder location. Renaming an unchanged archive therefore does not change its content hash.

Changing line endings, adding a final newline, or saving text in a different encoding changes the bytes. Two documents that look identical in an editor can consequently have different hashes. An extracted file also has a different byte representation from the archive that contained it.

Before calculating anything, identify the exact release, platform, architecture, and package format associated with the reference. A Windows installer and a Linux archive should not match, even if they install the same application version.

This is also why comparing only the beginning of a hash is inadequate. Use the entire value in the same representation. Hexadecimal letters can be upper- or lowercase without changing the number they represent; hex encoding is a display format for the digest bytes.

How to Verify a File in PowerShell

For a downloaded file named installer.iso, calculate SHA-256 with:

Get-FileHash -LiteralPath '.\installer.iso' -Algorithm SHA256

The output identifies the algorithm, calculated hash, and file path. Compare the complete hash with the reference for that exact download.

For a repeatable comparison, the following example reads a reference you provide. It expects only the 64 hexadecimal characters, without a filename or algorithm label:

$expectedHash = (Read-Host 'Paste the publisher SHA-256 value').Trim()

if ($expectedHash -notmatch '^[0-9A-Fa-f]{64}$') {
    throw 'Expected a complete SHA-256 value.'
}

$actualHash = (
    Get-FileHash -LiteralPath '.\installer.iso' -Algorithm SHA256
).Hash

if ($actualHash -ieq $expectedHash) {
    'The file matches the supplied SHA-256 value.'
} else {
    throw 'Checksum mismatch: investigate before using this copy.'
}

The format check catches an incomplete or incorrectly pasted reference. It does not authenticate that reference. Obtain it through the publisher’s trusted distribution process before using the result to make a decision.

What Causes a Checksum Mismatch?

A mismatch establishes that the calculation did not produce the expected value. It does not identify where the disagreement originated.

Start by checking the reference and input:

Question	Why it matters
Is this the correct release and platform?	Different builds have different contents.
Is the algorithm the same?	Different algorithms produce different digests.
Was the file transformed or extracted?	The reference may apply to the original archive.
Is the transfer complete?	A partial copy cannot match the complete file.
Is the file still being written?	Verification needs a stable input.

If these agree, obtain a fresh copy from the trusted source and compare again. Retain relevant details if the mismatch recurs. Repeated failures across unrelated files justify a broader investigation of the transfer and storage path; one mismatch alone is weak evidence of a faulty drive.

Follow the evidence rather than changing several things at once. When recording repeated failures, structured logs can keep file identifiers, transfer attempts, and mismatch results searchable. Distinguish those observations from a theory about their cause.

A Checksum Cannot Repair or Authenticate a File Alone

The digest does not contain enough information to reconstruct the original file. Recovery requires another source, such as a known-good copy, backup, or redundant storage. Some systems combine detection with repair, but the checksum is only the detection part.

A matching cryptographic hash also depends on the reference being trustworthy. If someone replaces both a download and its published hash, their modified file can pass the comparison. A signed manifest or digital signature can help establish origin when the verification key is authenticated through a trusted process.

Even a valid publisher signature does not prove that software is harmless or free of defects. It provides a different kind of evidence about origin and integrity.

Use the Result for the Question It Answers

A checksum is useful for checking a downloaded artefact, comparing a copied file, or detecting that stored content has changed. It does not explain the change, reverse it, or evaluate the contents as software.

For the installation image, a successful comparison against a trusted SHA-256 reference provides strong practical evidence that the expected bytes arrived. A mismatch is a reason to stop and investigate the file and reference. Keeping that interpretation precise makes the check a dependable part of handling data.

A checksum comparison is only as useful as the algorithm, the reference value, and the identity of the file being compared.