Skip to content
WordPress Maintenance

Hash Functions and Checksums: How Do We Detect a Corrupted or Altered File?

Hash Functions and Checksums: How Do We Detect a Corrupted or Altered File?

Next to a download link, you sometimes see a long string like sha256: 8b99fa28…. After making a backup, you may also want to confirm the copy isn’t damaged. In both cases, what does the work is a hash function or a checksum.

This article explains what they do, using small experiments with Python’s standard library. It stays with the general use of “telling whether two files are the same” and does not go into cryptographic or authentication implementation details.

Note: The numbers come from running Python 3 and its standard library (hashlib / zlib) on October 13, 2026. They are not measurements of any specific product or service.

What Is a Hash Function?

A hash function takes input of any length and returns a short, fixed-length value (a hash value, or digest).

Three properties are worth remembering:

  1. The same input always gives the same value
  2. A tiny change in the input gives a completely different value
  3. You cannot realistically recover the original data from the value

The first property is why hashes work for comparing files: the same file produces the same value.

What Changes With a One-Character Difference?

These two strings differ only in the last character (! vs ?):

  • Hello, checksum!
  • Hello, checksum?

Their SHA-256 values were:

Input SHA-256 (64 hex characters)
Hello, checksum! 8b99fa28a4076b2b…084221f
Hello, checksum? d4469d31724debb7…1690eed

They share nothing recognizable. Comparing the two values as bits, 139 of 256 bits differed — about half. You cannot tell from the values that the inputs were similar.

Also, empty input (0 bytes) still produces a value. For SHA-256 it is always 64 characters, and the value for empty data is fixed at e3b0c442…b855. Whether the input is one character or 10 MB, the output length does not change.

Can We Detect One Flipped Bit in 10 MB?

I ran a more realistic test. I generated 10 MB (10,485,760 bytes) of random data, flipped a single bit near the middle, and compared the values before and after.

Method Before After
SHA-256 (first 16 chars) 5f8058d32a23c184 e9ec8934165d9732
CRC32 0x27327ccb 0xea770c2f

Both methods showed the one-bit difference as a different value. Even when files are “almost identical,” a single bit changes the result, so both work for detecting corruption.

Hashing 10 MB with SHA-256 took about 0.004 seconds in this environment. For large files, reading from disk tends to dominate the time.

How Checksums Differ

In everyday use, “hash” and “checksum” are often treated as the same thing. By purpose, though, they can be separated:

Name Main purpose Examples
Checksum Catch accidental damage (transfer errors, failed writes) with a light computation CRC32, Adler-32
Cryptographic hash Catch accidental damage and also withstand deliberate tampering by design SHA-256, SHA-512

CRC32 is cheap to compute and short — 32 bits, or 8 hex characters. It is widely used inside transfer and archive formats to find accidental damage.

Because the value is short, though, different data is more likely to share a value than with a cryptographic hash. And CRC32 is not designed to stop someone from altering content while keeping the value unchanged.

That gives a practical split:

  • Detecting accidental damage (is the backup copy intact?): CRC32 is enough, though SHA-256 costs little extra
  • Checking that a downloaded file matches what was published: use SHA-256 or stronger

MD5 and SHA-1 are in the standard library too, but they are no longer recommended where resistance to deliberate tampering is expected. For anything new, SHA-256 or stronger is the safe default.

The Basic Verification Flow

Verifying a file’s integrity comes down to three steps:

  1. Record the hash value while the file is known to be good (the value published by the source, or one you recorded at backup time)
  2. Recompute it with the same method when you want to check
  3. Compare the two values. If they match, the content is the same; if not, something changed

Here is a Python example that reads the file in chunks, so even large files don’t use up memory:

import hashlib

def file_sha256(path, chunk_size=1024 * 1024):
    h = hashlib.sha256()
    with open(path, "rb") as f:
        while chunk := f.read(chunk_size):
            h.update(chunk)
    return h.hexdigest()

On the command line, shasum -a 256 filename (macOS) or sha256sum filename (Linux) gives the same value.

Four Points to Watch

1. A match only means something if the recorded value is trustworthy

Comparing hashes tells you only whether the content is the same as when the value was recorded. A hash stored in the same place as the file is meaningless if both were altered together. Get or store the value through a different route from the file to make the check worth something.

2. Make sure the method matches before comparing

A SHA-256 value and a SHA-1 value differ in both length and content. When comparing, confirm which method produced each value. Writing the method name next to the value saves confusion later.

3. Line endings and character encodings change the value

Text that looks identical can hash differently if its line endings (LF vs CRLF) or character encoding differ. The hash is computed over the actual bytes, not the characters you see on screen. If “the same file” gives a different value, suspect this first.

4. A hash is not the answer to storing passwords

Hash functions are also used to store passwords, but that use has different requirements from file verification (deliberately slow computation, adding a salt, and so on). Do not reuse a plain SHA-256 file check for password storage. It is enough here to know the purposes differ.

Summary

  • A hash function turns data of any length into a fixed-length value. The same input gives the same value; a one-bit change gives a different one
  • Checksums (CRC32 etc.) are for catching accidental damage; cryptographic hashes (SHA-256 etc.) are designed to withstand deliberate changes too
  • In the 10 MB experiment, flipping one bit was detected by both SHA-256 and CRC32
  • When verifying, check that the recorded value is trustworthy, the methods match, and you are comparing actual bytes

When you copy, back up, or distribute files, a habit of confirming “did we get the same thing?” by value saves time hunting for causes later. For another article about confirming outcomes, see What Is Idempotency?.