Hash Comparison

What is a hash comparison?

A cryptographic hash function takes any amount of data — a single character, a multi-gigabyte file — and compresses it into a fixed-length string of bytes called a digest. Change one bit of the input and the digest changes completely. The mathematical guarantee is that you cannot reverse a digest back into the input, and — for secure algorithms — you cannot find two different inputs that produce the same digest.

A hash comparison puts two or more algorithms side-by-side on the same input. It reveals how output length, character set, and speed differ between algorithms, and it makes concrete what "collision resistance" actually means in practice: two algorithms can produce wildly different fingerprints from the same text, and only one of them might be safe to rely on for security.

MD5 — fast, legacy, and broken

MD5 was designed by Ronald Rivest in 1991 and produces a 128-bit (32 hexadecimal character) digest. It was the dominant checksum algorithm for two decades, embedded in everything from email integrity checks (MIME) to Linux package verification to file download mirrors.

In 2004, cryptographers demonstrated that MD5 collisions can be produced in seconds on a standard laptop — two different PDF files, for instance, that share the same MD5 hash. By 2012, a chosen-prefix collision attack meant an attacker could take any two arbitrary messages and construct two with identical MD5 digests. This effectively destroyed MD5 for any security-sensitive purpose.

MD5 remains in use for non-adversarial checksums: detecting accidental corruption in file transfers, caching keys, and deduplication. If no one is actively trying to forge a collision, MD5 is perfectly fine — and it is fast. The table above shows its short 32-character output next to its successors, making the evolution visually obvious.

SHA-1 — still in use, officially deprecated

SHA-1 produces a 160-bit (40 hex character) digest and was designed by the NSA, published in 1995. It replaced MD5 as the default choice for digital signatures and TLS certificates, and it appeared in Git, Mercurial, SVN, and every major version control system.

In 2017, Google and CWI Amsterdam produced the first public SHA-1 collision — the "SHAttered" attack — showing two PDF files with identical SHA-1 hashes. Shortly after, the attack was improved to practical chosen-prefix collisions. Certificate authorities stopped issuing SHA-1 certificates in 2016, and browsers have rejected them since 2017.

SHA-1 is still used internally in Git for repository integrity (not security), HMAC in some legacy APIs, and fingerprinting in various non-adversarial systems. For new work, SHA-256 should be the default; SHA-1 should appear only in legacy or non-security contexts.

SHA-256 — the modern standard

SHA-256 is part of the SHA-2 family published by NIST in 2001. It produces a 256-bit (64 hex character) digest and is the algorithm behind Bitcoin's proof of work, TLS certificate signatures, software signing, document integrity, and the majority of modern cryptographic protocols.

SHA-256 has no known practical collision or preimage attack. It is computed natively by the Web Crypto API in every modern browser — which is why AnyHash can offer it at hardware-accelerated speed with zero external dependencies. A single SHA-256 digest of a short string completes in microseconds on any modern device.

The 256-bit output provides a 128-bit security margin against collision attacks (birthday bound), which is far beyond anything an attacker can achieve with current or foreseeable hardware. For file integrity, digital signatures, HMAC, and any protocol that needs a fixed-length fingerprint, SHA-256 remains the safe default in 2026.

SHA-512 — when 256 bits is not enough headroom

SHA-512 is the 512-bit member of the SHA-2 family, producing a 128 hex character digest. It uses 64-bit words internally, which on 64-bit CPUs can be faster than SHA-256 (which uses 32-bit words) — a counterintuitive fact that makes SHA-512 the speed champion of the SHA-2 family on modern desktop hardware.

SHA-512 matters in two scenarios. First, the 512-bit output provides a 256-bit collision resistance margin, which is useful in key derivation functions (HKDF, PBKDF2) where the derived key material must resist quantum birthday attacks. Second, in protocols where output length is used as a security parameter — like some digital signature schemes — SHA-512 gives a meaningful upgrade over SHA-256 at negligible cost.

SHA-512/256 is a truncated variant that produces a 256-bit digest using the SHA-512 internal structure, giving SHA-512's speed with SHA-256's output length. It is sometimes a better choice than SHA-256 for performance-sensitive applications on 64-bit platforms, though library support is less universal.

BLAKE3 — the modern speed champion

BLAKE3 was finalized in 2020 by Jack O'Connor, Samuel Neves, Jason A. Donenfeld, and Zinc Mint. It is derived from BLAKE2 — itself a PHC finalist — and uses the ChaCha quarter-round as its core mixing function, parallelized via a Merkle tree structure that makes it embarrassingly parallel on any number of cores.

On a single modern CPU core, BLAKE3 is roughly 10–20× faster than SHA-256. With SIMD and multi-threading, the advantage grows further. BLAKE3 produces a 256-bit output (with optional key derivation and keyed modes), and its tree structure means it can hash arbitrarily long inputs without the sequential bottleneck that limits MD5 and SHA-family algorithms.

BLAKE3 is not yet as universally deployed as SHA-256 — it lacks native Web Crypto API support, which is why this page loads it via the hash-wasm WebAssembly build. But for new systems that can choose their hash function freely — file deduplication, content-addressed storage, checksums, and general data integrity — BLAKE3 is the fastest correct choice available in 2026.

SHA-224 and SHA-384 — handier SHA-2 sizes

SHA-224 is SHA-256 truncated to 224 bits with a different initial constant, and SHA-384 is SHA-512 truncated to 384 bits. Both belong to the SHA-2 family and share the Merkle–Damgård structure of their larger siblings, so the security story is identical: no practical collision or preimage attack is known against either.

Where do they matter? SHA-224 is used in some TLS 1.2 and IPsec contexts, and SHA-384 remains common in firmware signing and TLS certificate signatures where a 512-bit internal state is wanted but a full 512-bit output is unnecessary. In a world where SHA-256 is the universal default, the truncated variants are mostly a compatibility and bandwidth play rather than a security upgrade.

SHA-3 — the modern standard (Keccak)

SHA-3 was selected by NIST in 2012 as the winner of the open SHA-3 competition and standardized in FIPS 202. Unlike MD5, SHA-1, and SHA-2 — which are all built from the Merkle–Damgård construction on top of a compression function — SHA-3 is built from a sponge construction on top of the Keccak permutation. That change of architecture gives it two practical differences: it is structurally immune to length-extension attacks, and it can have its output length stretched (SHAKE128, SHAKE256) as an extendable-output function (XOF).

The standard defines four digest sizes — SHA-3-224, SHA-3-256, SHA-3-384, and SHA-3-512 — each providing security comparable to the equivalently named SHA-2 size. In software SHA-3 tends to be slower than SHA-2, but its Keccak permutation is extremely hardware-friendly, which is why it is the hash of choice on many modern FPGAs and ASICs (including most IPv6/IPsec devices since the mid-2010s).

BLAKE2b and BLAKE2s — speed without sacrifice

BLAKE2 was designed in 2012 by Jean-Philippe Aumasson and others as a fast replacement for MD5 and SHA-1, reusing the ChaCha stream-cipher core that made its SHA-3 competition entry BLAKE so fast. It comes in two main flavors: BLAKE2b targets 64-bit platforms with up to 512-bit outputs, and BLAKE2s targets 32-bit platforms and small devices with up to 256-bit outputs. Both beat SHA-2 across the board while offering collision and preimage resistance at the same level.

BLAKE2 is the hash inside many real systems: Argon2 (the password-hashing winner on this site's Argon2id guide) uses the BLAKE2b permutation, Zcash uses BLAKE2b-512, and BLAKE2s is used in Bitcoin Cash's ecosystem and in key derivation all over the field. It also supports a keyed mode (a natural HMAC replacement) and optional output truncation down to any length.

RIPEMD-160 — the legacy survivor

RIPEMD-160 is a 160-bit hash from the European RIPE project, published by Hans Dobbertin, Antoon Bosselaers, and Bart Preneel in 1996. It was designed as an independent alternative to the NSA-designed SHA family — a genuine advantage in the 1990s patent climate. It remains best known for two decades of use inside Bitcoin: P2SH and legacy Bitcoin addresses are hashes of hashes ending in RIPEMD-160, and it appears throughout the cryptocurrency and legacy PGP world.

Cryptanalytically, RIPEMD-160 has aged better than MD5 — no practical collision is known — but its 160-bit output is small by modern standards and it offers nothing that SHA-256 does not. It survives for compatibility; it is not recommended for new work.

Whirlpool — AES-shaped and thorough

Whirlpool is a 512-bit hash designed by Vincent Rijmen (of AES fame) and Paulo Barreto in 2000, standardized as ISO/IEC 10118-3. Rather than relying on a fresh construction, it reuses the components of the AES block cipher — including its 8×8 state and diffusion layer — as the core of its compression function.

Whirlpool was a plausible choice when it appeared and is still formally standardized, but it is slow in software, has a small ecosystem, and offers nothing today's SHA-2, SHA-3, or BLAKE2 cannot do better. It is included here because it still turns up in legacy enterprise and government systems where the ISO standard was once mandated.

CRC32, xxHash, MurmurHash3, FNV-1a — fast, non-cryptographic

The last group in the live tool is a different breed: non-cryptographic hashes. They are designed for one property — speed — and not for adversarial resistance. An attacker can collide any of them in microseconds, so never use them for integrity verification or anything security-sensitive. Their job is hash tables, checksums, deduplication, and data processing where inputs are not hostile:

• CRC32 is the oldest: a cyclic redundancy check designed for detecting accidental corruption transit and storage. It sits inside ZIP, PNG, gzip, Ethernet, and countless disk/file formats. It is not a "hash" for uniqueness — only an error-detection code.
• xxHash is one of the fastest streaming hashes in existence, available in 32-, 64-, and 128-bit sizes, with a seeded, resumable API. It is used by Linux kernel (fast hashing of inode/file-path lookup), RocksDB and databases, and network tools for mailbox-style mapping.
• MurmurHash3 is a famous hash-map hash — Cassandra, Hadoop, Redis, and many in-memory caches use it. It excels at distributing keys across buckets with minimal collisions.
• FNV-1a is the tiny, teachable hash of the 1990s: a multiply-and-xor loop that fits in a few lines of any language. Still used in DNS resolvers, compilers, and hash maps where simplicity beats the newest hardware-tuned hash.

A useful dividing line: if an algorithm's output can be predicted or forged by an adversary without you noticing, it is only a checksum. MD5 and SHA-1 sit between these worlds — fast enough to be tempting for non-secure jobs, and broken enough that they must not be used for security.

Similarity, fuzzy, and perceptual hashes

None of the algorithms above answer a different kind of question: how similar are two inputs, rather than are they identical? A cryptographic hash avalanches completely on a one-bit change, which is exactly wrong for similarity. A family of specialized hashes exists for that job — and none of them are cryptographic:

• SimHash turns text into a fixed-size bit vector (commonly 64 or 128 bits). Similar documents land at a small Hamming distance from each other, letting a search engine cluster near-duplicates. It has been used at web search scale for exactly that purpose. Similarity detection.
• MinHash approximates the Jaccard similarity between sets by hashing shingles (small token windows) and keeping the minimum hash per hash function. Its signature is a list of those minima; the overlap of the lists estimates resemblance. It is the workhorse of near-duplicate detection and large-scale deduplication. Approximate similarity / deduplication.
• TLSH (Trend Micro Locality Sensitive Hash) is a "fuzzy" digest that produces a short hexadecimal fingerprint robust to minor modifications — three bytes changed in a malware sample still yield a nearby TLSH, which is why anti-malware feeds index by it. Fuzzy hashing.
• ssdeep is the original fuzzy hashing tool: it uses context-triggered piecewise hashing to split a file into blocks and hash each, producing a variable-length digest. A similarity score of 0–100 tells you how closely two files match — a staple of malware triage and document versioning. Fuzzy hashing.
• Perceptual image hashes — aHash (average grayscale), dHash (per-pixel difference), pHash (DCT based, most robust), and wHash (wavelet based) — reduce an image to a k-bit fingerprint stable under resizing, re-compression, and minor edits. They power reverse-image search, duplicate-photo cleanup, and video fingerprinting. They operate on images, not text, and are deliberately non-cryptographic. Image similarity.

These hashes have no place in security: their whole point is that similar inputs produce similar outputs. If you need to find near-duplicates among millions of files or images, reach for SimHash/MinHash/pHash-family tools; if the question is whether a file is byte-identical or tampered with, use a cryptographic hash instead.

Output lengths at a glance

The last nine rows — SimHash, MinHash, TLSH, ssdeep, and the four perceptual image hashes — are similarity, fuzzy, and perceptual tools, not cryptographic hashes, and are not part of the typing tool above. Every other row is computed live on this page. Output length is not the only security metric — it also determines storage and bandwidth costs. A SHA-512 digest is four times the size of a SHA-256 digest, which matters when you are hashing millions of objects for a content-addressed store or blockchain.

Sample digests of the same message

To make the difference concrete, here is the digest each algorithm produces for the single word password, encoded as UTF-8:

Above is the complete set this tool computes — 20 algorithms over the same password input. The digest byte length varies by design: 8 hex characters for the 32-bit checksums (CRC-32, xxHash32, MurmurHash3), 16 for the 64-bit ones (xxHash64, FNV-1a), 32 for SHA-224-derived 256-bit digests and MD5's 128 bits, 40 for RIPEMD-160's 160 bits, 64 for the SHA-256 and BLAKE families, 96 for SHA-384 and SHA-3-384, and 128 for the 512-bit hashes. A 256-bit security level needs no longer output than 64 characters — which is why BLAKE3 and SHA-256 look "short" next to SHA-512.

Second, the digests share nothing with each other: there is no visible pattern linking one algorithm's output to another's. The only guaranteed property is the fixed length for a given algorithm — hashing password and hashing a 10 MB file both yield exactly the same number of hex characters for the same algorithm.

That is why these digests are safe to publish next to a download: an attacker who sees the checksum learns nothing about the file contents, and anyone who changes one byte produces a dramatically different digest. It is also why the rows above are worth keeping as sanity checks when you are testing a new implementation — the MD5 and SHA-256 values appear in countless tutorials and are the quickest way to confirm your tooling is wired correctly.

Speed comparison

Raw speed depends heavily on the platform, but the relative ranking is consistent across modern hardware. On a single core of a 2024 laptop CPU, approximate throughput for short strings is:

The takeaway: BLAKE3 is in a different class. MD5 and SHA-1 are close; SHA-512 is faster than SHA-256 on 64-bit hardware due to its native word size. For single-hash latency on short inputs — as in this comparison tool — all five complete in microseconds, and the difference is imperceptible to the user. The speed advantage of BLAKE3 only becomes meaningful at scale: millions of files, streaming checksums, or content-addressed storage where the hash function is the bottleneck.

Collision resistance

A collision is when two different inputs produce the same digest. For a secure hash function, finding a collision should be computationally infeasible — requiring roughly 2^n/2 work for an n-bit hash (the birthday bound).

• MD5 (128-bit): Collisions can be found in seconds on a laptop. Chosen-prefix collisions — the stronger variant — were practical by 2009. MD5 is broken.
• SHA-1 (160-bit): A chosen-prefix collision was demonstrated in 2017 for roughly $110,000 in cloud compute. SHA-1 is deprecated.
• SHA-256 (256-bit): The best known attack requires approximately 2¹²⁸ work — roughly a century of global computing power. No practical weakness is known.
• SHA-512 (512-bit): The best known attack requires approximately 2²⁵⁶ work — physically impossible with any foreseeable technology.
• BLAKE3 (256-bit): Same collision resistance as SHA-256. Its tree structure does not weaken the Merkle-Damgård-equivalent security margin.

The practical lesson: use SHA-256 or BLAKE3 for anything where collision resistance matters — file integrity, digital signatures, content addressing. Use MD5 only for non-adversarial checksums. Never use SHA-1 for new security work.

A common question is whether quantum computers change this picture. Grover's algorithm halves the effective preimage security of any hash: SHA-256 would drop from 256 bits to 128 bits against a hypothetical large quantum machine. But even a perfect Grover attack leaves 128-bit preimage security for SHA-256 and BLAKE3, which the community still considers safe, and it barely affects collision resistance at all, because the birthday bound is already rooted in square roots. None of today's hash functions are considered quantum-vulnerable in the way RSA or Diffie-Hellman are, and there is no "post-quantum hash" needed — the algorithms above are already the post-quantum choice.

Which algorithm should I pick?

The right hash function depends entirely on the task:

• File checksum / download verification: SHA-256 is the safe default. BLAKE3 is faster if your tooling supports it. MD5 is acceptable for legacy compatibility (package managers, mirrors).
• Digital signatures / TLS certificates: SHA-256 or SHA-512. SHA-1 is rejected by all modern browsers.
• Content-addressed storage / deduplication: BLAKE3 (fastest), SHA-256 (most universal).
• HMAC / message authentication: SHA-256-HMAC or SHA-512-HMAC. BLAKE3 has a keyed mode that is faster but less widely deployed.
• Password storage: None of these five. Use Argon2id or bcrypt — see our Argon2id guide.
• Random token generation: SHA-256 of a UUID or high-entropy string, truncated to the desired length. Or use crypto.getRandomValues directly.

The table above gives you an instant visual of what each algorithm produces. For most new work, SHA-256 is the right choice; if you need raw speed and your stack supports BLAKE3, prefer it.

How this comparison tool works

• MD5 uses a pure-JavaScript implementation (RFC 1321), because the Web Crypto API intentionally omits MD5 — it is cryptographically broken. The implementation lives in src/scripts/md5.ts and is a faithful single-file translation of the reference algorithm.
• SHA-1, SHA-256, and SHA-512 use the native Web Crypto API (crypto.subtle.digest), which is hardware-accelerated on modern devices. This means these three digests are computed with the same speed and correctness as a native OpenSSL call.
• BLAKE3 uses hash-wasm, a WebAssembly build of the reference implementation. It loads once and stays cached; subsequent hashes are nearly instant. BLAKE3 has no Web Crypto API equivalent, which is why the WASM module is needed.
• All five run in parallel. On every keystroke (after a 200 ms debounce), the five computations are dispatched via Promise.allSettled so a slow WASM init never blocks the faster Web Crypto calls. The results appear in the table as each completes.
• Zero uploads. The page, fonts, scripts, and WASM binary are all served from the same origin. Your input never appears in a network request — you can verify this in your browser's DevTools.

Verifying hashes across tools

One practical use of this comparison page is cross-validation: if you generate an MD5 checksum in a different tool and want to confirm it matches, paste the same input here and compare. The MD5, SHA-256, and SHA-512 outputs are guaranteed to match any standards-compliant implementation — the algorithms are deterministic and the implementations are well-tested.

BLAKE3 outputs match the reference implementation and any BLAKE3 library in any language, since the algorithm is fully specified. The only variation you might see is case: this tool always outputs lowercase hex. Some tools default to uppercase. The byte values are identical.

If you are comparing hashes for file integrity, remember that the input encoding matters. This tool hashes the UTF-8 encoding of the typed text. A file's raw bytes may differ — for example, a Windows text file with CRLF line endings will produce a different hash than the same content with LF endings. Always compare hashes computed over the same byte sequence.