Cryptographic Hash Functions: SHA-256, MD5, and Beyond

A cryptographic hash function must satisfy three formal properties. Preimage resistance means that given only a digest, it is computationally infeasible to find any input that produces it — the function cannot be run backwards. Second-preimage resistance means that given a specific input, it is infeasible to find a different input with the same digest. Collision resistance, the strongest requirement, means it is infeasible to find any two distinct inputs that hash to the same value.

These properties exist on a spectrum of difficulty. Because of the birthday paradox, finding an arbitrary collision in an n-bit hash takes roughly 2^(n/2) operations, while finding a preimage takes around 2^n. This is why a 256-bit hash like SHA-256 offers about 128 bits of collision resistance — still far beyond any feasible attack — and why hash output sizes are chosen to leave a comfortable margin against brute force.

Closely related is the avalanche effect: a good hash function diffuses every input bit across the entire output, so flipping one bit of the message changes about half of the output bits in a way that looks random. Without strong diffusion, an attacker could make controlled, predictable changes to a digest, which would undermine integrity checks and signatures. You can observe the avalanche effect directly by changing one character of an input in the Hash Generator and watching the digest change completely.

It is essential to understand that hashing is one-way and is not encryption. Encryption is reversible by design — anyone with the key can recover the plaintext — whereas a hash deliberately destroys information so the original cannot be reconstructed from the digest. There is no key and no decryption step. Any product or tutorial that claims to decrypt a SHA-256 hash is either describing a precomputed lookup of common inputs or is simply wrong about how hashing works.

SHA-256 produces a 256-bit (32-byte) digest and is the most widely deployed cryptographic hash in production systems today. It secures TLS certificates, signs software and operating system updates, anchors the proof-of-work in Bitcoin, and verifies the integrity of countless file downloads. As of 2026 there are no practical attacks against SHA-256; its preimage and collision resistance remain at full strength, and it is recommended by NIST for general-purpose use.

SHA-256 is one member of the SHA-2 family, which also includes SHA-224, SHA-384, SHA-512, and the truncated SHA-512/256. They share the same Merkle-Damgard construction but differ in word size and output length. SHA-512 actually runs faster than SHA-256 on most 64-bit hardware because it operates on 64-bit words, so for purely internal use on modern servers, SHA-512 or SHA-512/256 can be a better default while offering a larger security margin.

The Merkle-Damgard structure that SHA-2 uses has a known quirk called the length-extension property: given the hash of a secret-prefixed message, an attacker can compute the hash of that message plus an extension without knowing the secret. This does not break SHA-256 as a hash, but it does make the naive construction hash(secret || message) unsafe for authentication. The correct fix is HMAC, covered below, which is specifically designed to neutralize length-extension.

For everyday work, SHA-256 is a sound default: compute a digest of a file and compare it against a published checksum to confirm the download was not corrupted or tampered with, or use it to generate stable content identifiers for caching and deduplication. The Hash Generator computes SHA-256 and the other SHA-2 variants instantly in your browser, so the data being hashed never leaves your device.

SHA-3 was standardized by NIST in 2015 as the winner of a public competition, and it is built on the Keccak algorithm. Crucially, SHA-3 is not a patch or successor that fixes a flaw in SHA-2 — SHA-2 was and remains secure. SHA-3 was standardized to provide a structurally different alternative, so that if a future breakthrough ever weakened the Merkle-Damgard family, the world would already have a vetted, deployed backup based on entirely different internals.

Instead of Merkle-Damgard, SHA-3 uses a sponge construction. Input is absorbed into a large internal state through a permutation, and output is then squeezed out of that state. A direct benefit is that the sponge is naturally immune to the length-extension attack that affects SHA-2, so SHA-3 can be used in some keyed constructions where plain SHA-256 would be unsafe. SHA-3 comes in the same output sizes as SHA-2 (224, 256, 384, 512 bits).

The sponge design also yields the SHAKE extendable-output functions, SHAKE128 and SHAKE256, which can produce a digest of any requested length. This is useful for applications that need a deterministic stream of pseudorandom bytes from a seed, such as key derivation or certain post-quantum signature schemes. In practice, SHA-3 adoption is growing steadily but SHA-2 still dominates because of its head start and excellent hardware support.

For most developers the practical guidance is straightforward: SHA-256 or SHA-512 remain perfectly safe and fast defaults, and you should reach for SHA-3 when a protocol specifically requires it, when you want length-extension immunity without HMAC, or when you need the variable-length output of SHAKE. Both families are appropriate for integrity and signatures; neither should be used directly for passwords.

MD5 produces a 128-bit digest and SHA-1 produces a 160-bit digest, and both are cryptographically broken. Practical collision attacks exist for each: MD5 collisions can be generated in well under a second on ordinary consumer hardware, and in 2017 the SHAttered research demonstrated the first real SHA-1 collision by producing two different PDF files with the same SHA-1 digest. Because collision resistance is gone, neither algorithm can be trusted for digital signatures, certificates, or any security decision.

The danger of a collision is concrete. If an attacker can craft two files with the same digest, a signature or approval applied to the benign file is equally valid for the malicious one. This is precisely how forged certificates and tampered software updates become possible when a broken hash is used in a trust chain. Every major certificate authority and browser deprecated SHA-1 for certificates years ago for exactly this reason.

MD5 and SHA-1 are not uniformly forbidden, however. For non-adversarial uses where you only need to detect accidental corruption or to bucket data — such as a checksum on an internal cache, a deduplication key, or an ETag — MD5 remains acceptable because no attacker is trying to engineer a collision. The rule of thumb is simple: never use MD5 or SHA-1 where an adversary could benefit from a collision, and prefer SHA-256 whenever the value crosses a trust boundary.

When you encounter MD5 or SHA-1 in existing systems, treat them as a migration signal rather than something to extend. New designs should default to SHA-256 or BLAKE3, and legacy verification can remain only until the data or protocol can be re-hashed under a modern algorithm. You can compute MD5 and SHA-1 alongside modern digests in the Hash Generator when you need to verify against an older published checksum.

BLAKE2 and its successor BLAKE3 are modern cryptographic hashes designed to be extremely fast while retaining full security. BLAKE2 was already faster than MD5 and SHA-1 despite being secure, and it is widely used in tools like the Argon2 password hasher and various version-control and storage systems. It offers BLAKE2b (optimized for 64-bit platforms) and BLAKE2s (for smaller architectures), with built-in support for keyed hashing and personalization.

BLAKE3, released in 2020, takes performance further with a tree-based (Merkle tree) internal structure that allows hashing to be parallelized across multiple CPU cores and SIMD lanes. On modern hardware BLAKE3 can be several times faster than SHA-256 while providing 256 bits of output and the same strong security guarantees. Its tree structure also enables verified streaming and incremental updates, which is valuable for large files and content-addressed storage.

Being faster does not make BLAKE3 less secure than SHA-256 for general use; both target the same security level, and BLAKE3's speed comes from clever engineering rather than from cutting cryptographic corners. The trade-off is maturity and ubiquity: SHA-256 has decades of scrutiny and is available in every standard library, hardware accelerator, and compliance regime, whereas BLAKE3 is newer and not yet mandated by standards like FIPS.

Choose SHA-256 when interoperability, compliance, or hardware acceleration matters, and consider BLAKE3 when raw throughput on large data is the priority and you control both ends of the system. As with every general-purpose hash, neither BLAKE2 nor BLAKE3 should be used by itself to store passwords — that requires a function deliberately tuned to be slow.

The single most important practical lesson about hashing is that you must not store passwords with a fast general-purpose hash such as SHA-256, even with a salt. Fast hashes are fast for attackers too: a modern GPU can compute billions of SHA-256 hashes per second, so if a database of SHA-256 password hashes leaks, an attacker can test enormous dictionaries and crack weak and moderate passwords almost immediately.

Password hashing requires functions that are deliberately slow and resource-intensive: bcrypt, scrypt, and the current best choice, Argon2. These algorithms expose a cost parameter (and for scrypt and Argon2, a memory parameter) that you tune so a single hash takes a meaningful fraction of a second on your server. That cost is trivial when verifying one login but multiplies into an impossible barrier when an attacker tries to test billions of candidates offline.

Salting is mandatory and complementary. A salt is a unique random value stored alongside each hash that ensures two users with the same password produce different digests, which defeats precomputed rainbow tables and prevents an attacker from cracking many accounts at once. Argon2 and bcrypt generate and embed salts for you; you should never hand-roll password storage with a bare hash and a shared salt.

In short, separate the two use cases cleanly. Use SHA-256, SHA-3, or BLAKE3 for integrity, signatures, checksums, and identifiers where speed is desirable, and use Argon2 (or bcrypt/scrypt) for passwords where slowness is the whole point. Conflating the two is one of the most common and damaging security mistakes in application development.

Hashing alone proves that data has not changed, but it does not prove who produced it, because anyone can recompute a public digest. To authenticate a message — to prove it came from someone holding a shared secret and was not altered in transit — you use a keyed construction called an HMAC (Hash-based Message Authentication Code). HMAC combines a secret key with the message and a hash function such as SHA-256 to produce a tag that only parties knowing the key can generate or verify.

HMAC is defined precisely so that it is not vulnerable to the length-extension weakness of SHA-2. The naive approach of hashing the key concatenated with the message, hash(key || message), is insecure for exactly that reason, whereas HMAC applies the hash twice with inner and outer key padding to close the gap. This is why you should always use a vetted HMAC implementation rather than inventing your own keyed hash.

HMAC-SHA256 is ubiquitous in practice. It signs API requests and webhooks so a receiver can confirm a payload genuinely came from the expected sender, it protects session tokens and cookies from tampering, and it underlies key-derivation functions like HKDF. The HMAC Generator lets you compute an HMAC over a message with a chosen key and hash algorithm to test or verify such integrations.

When verifying an HMAC, always compare tags using a constant-time comparison rather than an ordinary string equality check. A naive comparison can leak, through tiny timing differences, how many leading bytes matched, which an attacker can exploit to forge a valid tag byte by byte. Constant-time comparison removes that side channel and is provided by most cryptographic libraries.