Bcrypt Hash Generator & Verifier,
secure one-way hashing in your browser.

Bcrypt guide

What is bcrypt and why is it the right tool for password hashing?

The bcrypt algorithm

Bcrypt is a password-hashing function designed by Niels Provos and David Mazières in 1999, based on the Blowfish cipher. It was explicitly designed to be slow and computationally expensive — a property that makes it fundamentally different from general-purpose cryptographic hash functions like SHA-256 or MD5, which are optimised for speed.

The core insight behind bcrypt is that defenders only need to hash a password once (at login), but attackers must hash millions of candidate passwords when cracking a stolen database. By being expensive to compute, bcrypt makes brute-force and dictionary attacks impractical even with modern GPU hardware.

What is a salt, and why does bcrypt embed it?

A salt is a random value that is combined with the plaintext before hashing. Bcrypt generates a cryptographically random 22-character salt automatically and embeds it directly in the output hash string. This is why two calls to bcrypt.hash("password", 12)produce different 60-character strings — each has a unique embedded salt.

The salt defeats two major attack strategies:

• Rainbow tables — precomputed tables of hash → password mappings become useless when every hash is salted differently.
• Parallel cracking — an attacker cannot crack multiple accounts simultaneously with a single hash computation, because each account has a different salt.

Crucially, the salt is stored alongside the hash in the same string, so verification requires only the bcrypt hash itself — no separate salt column in your database is needed.

Understanding salt rounds (cost factor)

The salt rounds parameter (also called the cost factor or work factor) controls how many times bcrypt internally iterates its key derivation. Specifically, bcrypt performs 2^rounds iterations. Each increment doubles the computation time:

• 8 rounds — ~1 ms. Development and testing only. Far too fast for production.
• 10 rounds — ~80 ms. Acceptable minimum for low-traffic applications.
• 12 rounds — ~300 ms. The OWASP-recommended default for most applications.
• 14 rounds — ~1 s. High-security applications where UX allows a slight delay.
• 16 rounds — ~3–8 s. Extreme cases; only suitable with async or background queuing.

OWASP recommends calibrating the cost factor so that hashing takes at least 1 second on your production hardware. As hardware improves over time, you should increase the cost factor to maintain the same level of protection — this is the key benefit of an adjustable cost factor.

Reading the bcrypt hash string

A bcrypt hash is always exactly 60 characters and follows the Modular Crypt Format (MCF):

• $2b$ — The algorithm version. $2a$ is the original spec; $2b$ is the corrected implementation that fixes a carry-handling bug in some edge cases. Modern libraries use$2b$; both are widely accepted.
• 12$ — The cost factor (salt rounds), stored as a two-digit number.
• Next 22 characters — The base-64 encoded random salt, using bcrypt's custom alphabet.
• Remaining 31 characters — The base-64 encoded hash output, also in bcrypt's custom alphabet.

Bcrypt vs other hashing algorithms

• MD5 / SHA-1 / SHA-256 — General-purpose hash functions designed to be fast. A GPU can compute billions of SHA-256 hashes per second, making cracking trivial. Never use these for passwords.
• Argon2 — The winner of the 2015 Password Hashing Competition. Memory-hard by design, making GPU/ASIC cracking even harder than bcrypt. Preferred for new systems where Argon2 support is available.
• scrypt — Also memory-hard. Similar goals to Argon2. Used by Litecoin and some password managers.
• PBKDF2 — Required by FIPS 140-2 compliance. Not memory-hard, which makes it more vulnerable to GPU attacks than bcrypt at the same time cost.

For new projects, prefer Argon2id if available. For projects already using bcrypt, it remains secure and well-supported — the OWASP password storage cheat sheet explicitly lists bcrypt as an approved algorithm.

Common implementation mistakes

• Hashing the hash — Avoid calling bcrypt on an already-bcrypt-hashed value. Some misconfigured auth libraries do this accidentally during re-hashing on login.
• 72-byte truncation — The classic Blowfish implementation truncates input at 72 bytes. Passwords longer than 72 ASCII characters (or shorter in multi-byte encodings) are silently truncated. If you need to support long passphrases, pre-hash with SHA-256 before passing to bcrypt, or use Argon2 instead.
• Using bcrypt for data integrity — Bcrypt is a one-way function and cannot be reversed. Never use it to encrypt data you need to retrieve — use AES-GCM or another symmetric cipher for that.
• Cost factor too low in production — The default in many older tutorials is 10. With modern hardware, 12 is the practical minimum for anything serving real users.