MD5 vs. SHA-256 — Which Hash Function Should You Use?

MD5 and SHA-256 are both widely used hash functions but serve different purposes. Learn the differences and when each is appropriate.

What hash functions do

A hash function takes input of any size and produces a fixed-length output — the hash or digest — that uniquely represents that input. The same input always produces the same hash, but a single character change in the input produces a completely different hash. This property makes hash functions useful for verifying data integrity, storing passwords, and generating checksums.

Hash functions are one-way: you can compute the hash from the input, but you can’t compute the input from the hash. This is why they’re used for passwords — the stored value is the hash, and authentication checks whether a submitted password produces the same hash, without ever storing the password itself.

Generate hashes instantly with Hash Generator.

MD5: fast, widely supported, cryptographically broken

MD5 (Message Digest 5) produces a 128-bit hash, typically shown as a 32-character hexadecimal string. It was designed in 1991 and was the dominant hash function for two decades.

The problem with MD5: It’s cryptographically broken. Researchers have demonstrated collision attacks — scenarios where two different inputs produce the same MD5 hash. Generating a collision is computationally feasible on modern hardware, meaning MD5 cannot be relied upon to guarantee data uniqueness in security-sensitive contexts.

Where MD5 is still acceptable: Non-security uses where collisions don’t matter and speed does. Checksums for casual file integrity verification (where the threat model doesn’t include an adversary deliberately creating collisions), deduplication in databases, hash-based identifiers in internal systems, and partitioning data across shards are all contexts where MD5’s speed advantage makes it a reasonable choice.

Where MD5 is not acceptable: Password hashing (never), digital signatures, certificate fingerprints, or any context where an adversary might be motivated to produce a collision.

SHA-256: the current standard for security-sensitive hashing

SHA-256 is part of the SHA-2 family, designed by the NSA and published in 2001. It produces a 256-bit hash (64 hexadecimal characters). As of 2026, SHA-256 has no known practical attacks and is the recommended choice for any security-sensitive hashing need.

SHA-256 is used in TLS certificates, Bitcoin’s proof-of-work algorithm, code signing, HMAC authentication, and password hashing (as a component in algorithms like PBKDF2 and bcrypt).

It’s slower than MD5 — a meaningful difference at high volume but irrelevant for most single-use cases. For file integrity verification, checksums, and any security-adjacent application, SHA-256 is the appropriate choice by default.

SHA-1: the middle ground you shouldn’t use

SHA-1 produces a 160-bit hash and sits between MD5 and SHA-256 in the hash family. Like MD5, it has been cryptographically broken — a practical collision attack was demonstrated in 2017 (the SHAttered attack). SHA-1 should not be used for any new implementation.

Legacy systems that still use SHA-1 (some older TLS certificates, git’s internal hashing, certain file integrity tools) are gradually migrating to SHA-256 or SHA-3. If you encounter SHA-1 in an existing system, it’s a migration candidate.

SHA-512: when 256 bits isn’t enough

SHA-512 produces a 512-bit hash (128 hexadecimal characters). It’s not more secure than SHA-256 for most purposes — both are considered secure, and SHA-256 is sufficient for the vast majority of use cases.

SHA-512 can be faster than SHA-256 on 64-bit processors due to architectural differences, and it provides a larger margin against future advances in computing power. It’s used in high-security applications where the additional bit length is worthwhile.

The password hashing exception

Raw hash functions (MD5, SHA-256, SHA-512) should not be used directly for password hashing, regardless of which algorithm you choose. The reason: they’re designed to be fast, and fast is bad for password storage. An attacker can hash billions of password guesses per second on commodity hardware.

Password hashing requires slow algorithms specifically designed for this purpose: bcrypt, Argon2, scrypt, or PBKDF2 with a high iteration count. These functions include a salt (random data preventing rainbow table attacks) and a work factor that can be increased as hardware gets faster.

The Hash Generator is appropriate for file integrity, checksums, data deduplication, and learning about hash functions — not for implementing password storage in an application.

Choosing the right algorithm

Use caseRecommended algorithm
File integrity check, casual useSHA-256 or MD5 (if no adversary)
Security-sensitive checksumsSHA-256
Digital signaturesSHA-256 or SHA-3
Password hashingbcrypt, Argon2 (not raw SHA)
Legacy system compatibilitySHA-256 if possible, SHA-1 only if forced
High-security applicationsSHA-256 or SHA-512

When in doubt, use SHA-256. It’s widely supported, computationally secure, and the default choice in modern security standards.


✨ Missing something?
Can't find the tool you need?
Request it — we build new tools based on what people ask for.
Request a tool