MD5 vs SHA-256 for File Checksums

Use SHA-256 for file checksums. MD5 still detects accidental corruption, but practical collision attacks mean it cannot show that a file is the one its publisher intended; RFC 6151 states that MD5 is no longer acceptable where collision resistance is required. SHA-256 has no known practical collisions and is supported by the same everyday tools.

The longer answer depends on what you are protecting against: random errors, or a person who wants you to accept a different file.

What a checksum does

A cryptographic hash function turns any amount of data into a fixed-size digest. Change one bit of the input and the digest changes completely. Publishing the digest next to a download lets you recompute it after the transfer and compare:

$ printf 'hello\n' > file.txt
$ md5sum file.txt
b1946ac92492d2347c6235b4d2611184  file.txt
$ sha256sum file.txt
5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03  file.txt

Two different questions can be answered this way:

1. Integrity against accidents. Did the bytes arrive unchanged after a network or disk error? Almost any hash, even a simple CRC, catches this.
2. Integrity against attackers. Is this the exact file the publisher released, and not a different file crafted to have the same digest? That requires collision resistance, and it is where MD5 fails.

MD5 vs SHA-256 at a glance

What RFC 6151 says about MD5

RFC 6151 is the IETF's updated security guidance for MD5. Its key points:

• Published attacks show that "it is not prudent to use MD5 when collision resistance is required". The RFC cites work that finds an MD5 collision in about one minute on a standard notebook PC.
• MD5 must not be used for digital signatures, and such attacks have been demonstrated against X.509 certificates.
• An MD5 checksum included only to detect errors "is still an acceptable use".
• The best known pre-image attack is still far from practical, so finding a file that matches an existing MD5 digest you did not choose remains hard.

The last point is why MD5 checksums are not useless. The danger is a chosen collision: someone who controls the content can prepare two files, a harmless one and a malicious one, with the same MD5 digest, publish the hash of the harmless one, and later swap in the other.

When MD5 is still fine

• Detecting accidental changes in your own backups or file transfers.
• De-duplicating files you control, where nobody benefits from forging a match.
• Cache keys and ETags that are not security boundaries.
• Compatibility with an old system that only publishes MD5, as long as you treat the result as an error check, not a security check.

When you need SHA-256 (or stronger)

• Verifying downloaded software, firmware, disk images or packages.
• Any checksum that is published so that others can trust a file.
• Digital signatures, certificates and code signing.
• Integrity values for third-party resources, such as Subresource Integrity in HTML, which accepts SHA-256, SHA-384 and SHA-512 but not MD5.

Speed is rarely a good reason to keep MD5. Results depend on the CPU, and many current processors include hardware instructions for SHA-256, so measure before assuming MD5 is faster on your machines.

What about SHA-1 and SHA-512?

SHA-1 sits between MD5 and SHA-256: it is longer than MD5 but no longer trusted where collision resistance matters. If a project publishes both SHA-1 and SHA-256 sums, check the SHA-256 one. SHA-512 is as safe as SHA-256 for this purpose; pick whichever the publisher provides, and use SHA-256 when you publish your own, since it is the one most tools and users expect.

How to check a SHA-256 checksum

Linux

sha256sum ubuntu.iso                # print the digest
sha256sum -c SHA256SUMS             # check every file listed in a checksum file

A checksum file has one line per file: the digest, two spaces, the file name. sha256sum -c prints OK for each match and FAILED plus a warning for any mismatch.

macOS

shasum -a 256 file.dmg

Windows

Get-FileHash .\setup.exe -Algorithm SHA256
certutil -hashfile setup.exe SHA256

Browser JavaScript

async function sha256Hex(file) {
  const buf = await file.arrayBuffer();
  const hash = await crypto.subtle.digest("SHA-256", buf);
  return [...new Uint8Array(hash)].map(b => b.toString(16).padStart(2, "0")).join("");
}

The Web Crypto digest() method supports SHA-1, SHA-256, SHA-384 and SHA-512, but not MD5.

Compare the whole digest, not just the first few characters, and compare it with a value from a source you trust. Hex digests are case-insensitive, so 5891B5… and 5891b5… are the same.

A matching hash is only as good as its source

If the checksum sits on the same server as the file, an attacker who can replace the file can usually replace the checksum too. Stronger setups publish checksums over a separate channel, sign the checksum file with a key you already trust, or rely on package managers that verify signatures automatically. SHA-256 removes the collision problem; it does not remove the need to trust where the expected value came from.

Text hashes on this site

The universal encoder decoder computes MD5, SHA-1, SHA-256 and SHA-512 of text you type, which is handy for comparing short strings and test vectors. Note that hashing text is sensitive to every byte: hello and hello followed by a line break give different digests, which is why the printf 'hello\n' example above does not match the SHA-256 of hello alone (2cf24dba…9824). Digests are usually shown in hex; the Base64 vs hex guide explains why some tools print them in Base64 instead, and why Base64 makes data larger covers the size difference. HMAC signatures in tokens are built on the same hash functions; see how JWTs are decoded and verified.