SHA-256 vs MD5: What Developers Should Know

Hashing basics

A hash function maps input data to a fixed-length digest. Developers use hashes for comparisons, integrity checks, cache keys, and many protocol-level workflows.

A hash is not encryption. You cannot decrypt a SHA-256 or MD5 digest back to the original input.

MD5 collision weakness

MD5 is considered broken for collision resistance. That means attackers can create different inputs with the same MD5 digest under practical conditions.

MD5 may still appear in old checksums, legacy APIs, or documentation examples, but it should not be selected for modern security-sensitive integrity decisions.

Where SHA-256 fits

SHA-256 is widely used for modern digest and integrity workflows. It is a better default than MD5 for comparing files, creating non-secret content digests, and building test expectations.

Checksums are not password storage

Fast hashes such as MD5 and SHA-256 are not appropriate by themselves for storing passwords. Password storage needs dedicated password hashing algorithms with salts and work factors, such as bcrypt, scrypt, Argon2, or PBKDF2 depending on platform and policy.

Algorithm decision table

Checksum QA checklist

• Name the algorithm beside every digest.
• Hash the exact bytes, not a re-encoded text approximation.
• Normalize expected hex case only after calculation.
• Treat a matching checksum as integrity evidence, not publisher identity.
• Use dedicated salted password hashing for passwords.

Integrity is not authenticity

A digest changes when input bytes change, so it is useful for detecting accidental corruption. If an attacker can replace both a download and the checksum displayed beside it, a matching digest proves nothing about the publisher. Authenticity requires a trusted signature, authenticated channel, or another mechanism that protects the expected value.

Always record the algorithm next to a digest. A bare hexadecimal string is ambiguous, and its character length is only a clue. Normalize hexadecimal casing for comparison but never normalize the source bytes unless the protocol explicitly defines that transformation.

Why MD5 remains visible

MD5 is still encountered in legacy manifests, cache keys, database exports, and old integration tests. Reproducing a published MD5 checksum can be legitimate compatibility work. Designing a new security control around MD5 is not. Practical collision attacks mean two different inputs can be constructed with the same digest.

SHA-256 is a modern baseline for ordinary integrity checks, but it is also intentionally fast. Password storage needs a salted password hashing function with an adjustable work factor, such as the scheme selected by the authentication platform. A plain SHA-256 password digest is not an acceptable substitute.

Reproducible checksum checks

• Hash the file bytes rather than text produced by opening and re-saving the file.
• State UTF-8 or another encoding when hashing text.
• Compare algorithm, byte length, and hexadecimal digest together.
• Obtain expected checksums through an authenticated source when provenance matters.
• Keep MD5 and SHA-1 warnings visible in legacy workflows.
• Use known standard vectors in automated tests for every implementation path.

References

• NIST FIPS 180-4 Secure Hash Standard
• RFC 6151: MD5 Security Considerations
• OWASP Password Storage Cheat Sheet

FAQ

Related guides