Free Hash Generator — Argon2, Bcrypt, Scrypt, PBKDF2, SHA

Hashing is a one-way function. It takes any input and produces a fixed-length digest that cannot be reversed to recover the original data.

Encryption is two-way. Data scrambled with a key can be decrypted back to plaintext using the same (symmetric) or related (asymmetric) key.

Use hashing for integrity verification, password storage, and digital signatures. Use encryption for confidentiality — protecting data in transit (TLS) or at rest (disk encryption).

Never confuse the two. Hashing does not protect secrecy. Encryption does not provide tamper detection without additional mechanisms.

No. MD5 has known collision attacks that can produce two different inputs with the same hash in seconds on consumer hardware.

Never use it for security-sensitive purposes: password storage, digital signatures, certificate validation, or any scenario where an attacker could craft a collision.

The only acceptable use for MD5 today is non-security checksums — detecting accidental file corruption in legacy systems. Even then, SHA-256 is preferred.

For password hashing, use Bcrypt, Argon2, or PBKDF2 instead.

Cost factor 12-14 (4,096 to 16,384 iterations) is the current baseline for 2026. Increase as hardware improves.

scrypt and PBKDF2 should use an equivalent computational cost.

BetterPass's Bcrypt tool lets you adjust the cost interactively so you can benchmark your environment.

A salt is unique random data added to each input before hashing. It prevents rainbow table attacks and ensures identical passwords produce different hashes.

Bcrypt automatically generates and includes a unique salt in its output format. scrypt and PBKDF2 require you to provide a salt, which must be stored alongside the derived key.

Use HMAC when you need to verify both integrity and authenticity of a message using a shared secret key. Regular hashes only verify integrity.

HMAC is essential for API authentication, JWT signatures (HS256), and any scenario where you must prove the message came from someone who knows the secret key.

SHA-2 uses the Merkle-Damgård construction while SHA-3 uses the Keccak sponge construction.

SHA-3 is inherently resistant to length extension attacks and was designed as a backup if SHA-2 were ever broken. Both are NIST-approved.

SHA-3 offers post-quantum readiness and natively resists length extension attacks.

SHA-512/256 is preferred when you need 256-bit security with resistance to length extension attacks (unlike SHA-256).

It's faster on 64-bit CPUs due to its larger word size.

Use SHA-512/256 for key derivation and digital signatures where length extension resistance matters.

SHA-2 (especially SHA-256 and SHA-512) is generally faster than SHA-3 on most hardware. Modern CPUs include SHA-NI instruction set extensions that accelerate SHA-1 and SHA-256 operations; SHA-512's speed advantage comes from its 64-bit word size.

SHA-3 (Keccak) lacks widespread hardware acceleration as of 2026, making it 2-5x slower for bulk hashing.

However, SHA-3 wins where hardware SHA-3 accelerators exist (some ARM cores, FPGAs), when length extension resistance is needed without HMAC overhead, or for post-quantum readiness. For most server-side workloads, SHA-2 remains the performance leader.

A rainbow table precomputes hash chains for common passwords. It enables fast password cracking by reversing hashes without brute force, trading computation time for storage space.

Salting defeats this by appending unique random data to each password before hashing. With a 16-byte salt, an attacker would need a separate rainbow table for every possible salt. That's computationally infeasible.

Only Bcrypt auto-generates its salt. scrypt and PBKDF2 require a user-supplied salt.

Argon2 has three key parameters: memory cost (m), time cost (t), and parallelism (p).

OWASP recommends Argon2id with m=64MB (65536 KiB), t=3 iterations, p=4 threads as a 2026 baseline.

For high-security environments, increase memory to 128-256MB rather than iterations. Memory-hardness provides better GPU/ASIC resistance. For constrained environments (mobile, IoT), reduce to m=16MB, t=2.

Target about 100ms verification time and never reduce memory below 8MB. At 64MB, expect about 50-80ms authentication latency per verification on modern hardware. Try our Argon2 tool to benchmark different parameters.