MD5, SHA-1, and SHA-256: choosing a hash
Hashes are useful because a short digest can represent a file or message, but the word “hash” does not answer the security question by itself. MD5, SHA-1, and SHA-256 have different histories and properties. A matching value can help detect an accidental download error when the expected value came from a trustworthy publisher. It cannot, by itself, prove who published a file, protect a password database, or turn an unsigned download into an authentic one. This guide separates those jobs before choosing an algorithm.
The problem
A cryptographic hash function accepts arbitrary bytes and returns a fixed-length digest. A useful digest is deterministic: the same bytes give the same result. It is also designed so that changing bytes changes the digest in an unpredictable way. Those properties make hashes convenient for integrity checks, identifiers, build pipelines, and signatures. They do not make every digest algorithm equally safe against a deliberate adversary.
MD5 produces 128 bits and SHA-1 produces 160 bits. RFC 6151 and RFC 6194 document collision attacks and advise against using these functions where collision resistance matters. A collision means two different inputs can be constructed with the same digest. SHA-256 is part of the SHA-2 family specified by FIPS 180-4 and is the normal choice of these three for a new general-purpose integrity check. “Normal choice” is not a claim that it solves authentication or password storage.
The first question is therefore not “which short string looks strongest?” It is what decision the digest will support. Detecting accidental corruption, storing a password verifier, proving a publisher approved a release, and signing a legal record are different problems. Each has a different trust boundary and often needs a different primitive around a hash.
Worked example
Suppose a project publishes tool-4.2.zip and a SHA-256 value on its HTTPS release page. After downloading, calculate SHA-256 over the downloaded bytes and compare it character for character with the value shown on that trusted page. If they differ, stop: the file is incomplete, changed, or a different release. If they match, the local bytes match the bytes represented by that published reference.
That conclusion has an important condition. If an attacker can replace both the archive and the checksum on the page, a matching digest still occurs. The comparison does not prove the publisher's identity; it proves equality with the reference you obtained. A checksum copied from an untrusted mirror, an unsigned message, or a search result has no independent authority. Obtain release metadata through a publisher-controlled channel and check its identity separately.
Now contrast passwords. A service must never store a plain SHA-256, SHA-1, or MD5 password digest as its password database design. Fast general-purpose hashes let an attacker test guesses quickly after a database leak. Password storage needs a purpose-built, salted, adaptive password-hashing or key-derivation scheme selected and configured by the service. A user comparing a downloaded file is not performing password storage.
Procedure
For a download, identify the exact release name, version, and publisher before calculating anything. Download from the official release location where possible. Retrieve the checksum from a separate trusted location or a signed release manifest if the publisher provides one. Keep the filename and digest together so a checksum for version 4.1 is not accidentally compared with the 4.2 archive.
Calculate SHA-256 over the original downloaded file, not an extracted folder or a file opened and re-saved by another application. Copy the complete hexadecimal digest carefully. Comparison should reject a mismatch rather than silently trimming or changing bytes. If it differs, delete or quarantine the download and obtain it again; do not change the expected value merely to make the comparison pass.
For stronger origin evidence, follow the publisher's signature verification instructions. A digital signature binds release data to a private signing key; verification uses the associated public key and a trust decision about that key. Check the key fingerprint or certificate using a trustworthy channel, verify the signature over the intended release metadata, and consider revocation or updated-key guidance. A signature still needs correct key distribution and verification policy.
Technical explanation
Collision resistance asks whether an attacker can find any two different inputs with the same digest. Preimage resistance asks whether an attacker given a digest can find an input that yields it. Second-preimage resistance asks whether an attacker given one input can find another with the same digest. These properties are related but not interchangeable. A system must state which property its protocol assumes rather than treating a digest length as a universal score.
Known practical collisions make MD5 and SHA-1 unsuitable for new collision-sensitive uses such as certificates, signed artifacts, and document workflows. Existing legacy systems may still display them for non-security identifiers or migration compatibility, but their presence is not a recommendation. A modern SHA-256 checksum is preferable for a fresh file-integrity convention, while protocol requirements can call for other standardized algorithms and formats.
The digest does not contain a timestamp, a publisher name, or a promise that a file is safe to execute. It only describes bytes under one algorithm. Malware can have a perfectly valid SHA-256 checksum when the attacker supplied the reference too. Likewise, a valid signature says that a particular key signed data; it does not replace reviewing whether that key belongs to the expected publisher or whether the software fits your environment.
Common failures
One common failure is treating MD5 or SHA-1 as acceptable because a tool still offers them. Availability preserves interoperability, not security suitability. Another is using SHA-256 directly for passwords because it is newer than MD5. The speed that helps checksum a large file also helps offline guessing. Password schemes deliberately add salt and computational or memory cost, and their configuration changes with threat models and hardware.
Another failure is comparing only a prefix of a digest, accepting case or whitespace transformations without understanding the format, or hashing a text rendering rather than the binary file. These mistakes can create misleading “matches” or hide a mismatch. Use the format documented by the publisher, retain the full value, and rerun the calculation after any download retry.
Finally, do not publish a checksum beside a download and call it a signature. A checksum is useful for accidental corruption only when its reference is already trusted. If origin matters, publish verifiable signatures, clear key-distribution information, and release instructions. Users should not import keys from an arbitrary comment, ticket, or pasted chat message.
Considerations
Hashing can expose information about low-entropy inputs. If a value comes from a small predictable set, someone can calculate candidate hashes and compare them. Do not treat a hash as redaction for names, email addresses, short identifiers, or passwords. Salts, access controls, and a design that minimizes collection are different controls with different purposes.
Integrity checks also need operational care. Record the algorithm, full digest, artifact name, version, source URL, and date in release automation. Generate the checksum from reproducible build output where feasible and protect the publication path. Test a deliberately modified artifact during a release drill to confirm that a mismatch stops the workflow. These practices reduce accidental mistakes without claiming that a hash alone authenticates software.
When using a local hash generator, only submit material you are permitted to process. For sensitive files, prefer a verified local operating-system command or an approved internal workflow. A browser-based tool can demonstrate a calculation but cannot attest to the provenance of its input, the trustworthiness of a copied reference, or the security policy of the recipient.
Limitations
This guide is a conceptual comparison, not a replacement for a vendor's verification procedure, a cryptographic review, or incident response. It does not certify a release, key, website, password manager, or hash implementation. Standards and attacks evolve, so consult current publisher guidance and applicable protocol requirements for high-impact systems.
It also does not provide a private key, a usable password, or instructions for bypassing verification. If a checksum mismatch appears on software needed for work, preserve the evidence needed by your organization, contact the official publisher, and use a known-good source. Do not distribute the suspicious artifact merely so others can compare it.
Checklist
Choose SHA-256 rather than MD5 or SHA-1 for a new general file checksum. Compare the complete digest of the exact bytes against a reference obtained through a trusted publisher channel. Treat a match as byte equality with that reference, not proof of publisher identity. Use signatures and verified keys when origin matters. Use a salted adaptive password-hashing scheme for passwords, never a bare MD5, SHA-1, or SHA-256 digest. Keep algorithm, artifact, version, source, and verification result together, and stop on a mismatch.