Delimiter.live
17 entries

Hash Algorithm Comparison

Hash algorithms fall into two groups with opposite requirements. General-purpose hashes such as SHA-256 should be fast, and suit checksums and signatures. Password hashes such as bcrypt and Argon2 must be deliberately slow, because speed is what lets an attacker crack a stolen database. Using one where the other belongs is the most common mistake.

Choosing a hash is usually a two-step decision. First, is this a password? If so, the answer is Argon2id, scrypt or bcrypt, and nothing else on this page is appropriate. If not, the answer is almost always SHA-256.

The rest is detail: whether a shared secret is involved (use HMAC), whether you need interoperability with something older, and whether the algorithm you inherited is still safe to keep.

General-purpose hashes

9 entries

Fast by design. For checksums, signatures and integrity — never for passwords.

Algorithm Digest Status Use it for
MD5 128 bit, 32 hex Broken — practical collisions since 2004 Non-security checksums and legacy compatibility only. Never for signatures.
SHA-1 160 bit, 40 hex Broken — practical collision demonstrated 2017 Legacy compatibility only. Git still uses it for object naming, for historical reasons.
SHA-256 256 bit, 64 hex Secure — no practical attack The default choice. Checksums, signatures, certificates, content addressing.
SHA-512 512 bit, 128 hex Secure — no practical attack Where a specification requires it, or when benchmarked faster on 64-bit hardware.
SHA-3 / Keccak Configurable Secure — different internal design A structurally independent alternative to SHA-2. Immune to length extension.
BLAKE3 256 bit default Secure — very fast High-throughput hashing of large files. Not yet as widely supported.
CRC32 32 bit Not cryptographic Accidental corruption detection only. Trivial to forge deliberately.
xxHash 64 or 128 bit Not cryptographic Extremely fast. For hash tables, deduplication and change detection where no attacker is involved.
SipHash 64 bit, keyed Not a general hash Keyed, and designed to stop hash-flooding attacks on hash tables. Used internally by several languages for exactly that.

Password hashes

5 entries

Deliberately slow and salted. For storing passwords, and nothing else.

Algorithm Cost control Status Notes
Argon2id Time, memory and parallelism Current recommendation Winner of the Password Hashing Competition. Resists GPU and custom-hardware attacks through memory cost.
scrypt CPU and memory Strong Memory-hard. A good choice where Argon2 is unavailable.
bcrypt Cost factor Still acceptable Well understood and available everywhere. Silently truncates input beyond 72 bytes — a real trap with long passphrases.
PBKDF2 Iteration count Acceptable, weakest of the four Not memory-hard, so it resists GPU attacks poorly. Use only when a standard mandates it.
Plain SHA-256 or MD5 None Do not use Listed only because it is still found in the wild. Too fast, and unsalted by default, so a stolen database falls in hours. Migrate on next login.

Keyed hashing

3 entries

Proving a message came from someone holding the shared secret.

Construction Built on Status Notes
HMAC-SHA256 SHA-256 Secure The standard way to authenticate a message with a shared secret. Used by webhooks and API signing.
HMAC-SHA512 SHA-512 Secure Same construction, longer digest.
Naive H(secret + message) Any Merkle–Damgård hash Insecure Vulnerable to length extension: an attacker can append data and compute a valid digest without the secret. This is why HMAC exists.

Notes

  • "Broken" means collision resistance is broken: an attacker can construct two different inputs with the same digest. Preimage resistance still holds for MD5 and SHA-1, which is why they still detect accidental corruption.
  • A hash is not encryption. It is one-way by design, and there is no key that recovers the input. If you need to get the original back, you want encryption, not hashing.
  • Salting is what stops precomputed tables. Password hash functions generate and store a salt automatically; a bare SHA-256 does not, which is one of several reasons it is unsuitable for passwords.

Frequently asked questions

Which hash should I use if I only remember one?
SHA-256 for everything except passwords, and bcrypt or Argon2id for passwords. That single rule covers the overwhelming majority of real decisions correctly.
Is MD5 safe for anything?
Only where no attacker chooses the input: detecting accidental corruption, deduplicating your own files, generating a cache key. It cannot prove a file has not been deliberately tampered with, so it is unsuitable for downloads or signatures.
Why not hash passwords with SHA-256?
Because it is far too fast. A modern GPU computes billions of SHA-256 hashes per second, so a stolen database of them falls quickly. Password hashes are deliberately slow and memory-hard precisely to make that attack expensive.
What is length extension?
Given H(secret + message) and the message length, an attacker can compute H(secret + message + extra) without knowing the secret, because of how SHA-2 processes data in blocks. HMAC uses a nested construction that closes this. SHA-3 and BLAKE are immune by design.
Does bcrypt really ignore long passwords?
It truncates input beyond 72 bytes, so anything after that is silently ignored. With long passphrases this quietly reduces security. Argon2id has no such limit, and a common workaround is to pre-hash with SHA-256 before passing to bcrypt.

Related tools

All tools →
All references →

Last reviewed .