Bcrypt Hash Generator and Verifier with Cost

Why bcrypt for passwords

bcrypt is a password hashing function designed in 1999 by Niels Provos and David Mazières, based on the Blowfish cipher. Unlike MD5 or SHA-256, which are built to be fast, bcrypt is built to be slow, and it stays slow as hardware improves because of two properties.

First, an adaptive cost factor: the work is 2^cost rounds of key expansion, so raising the cost by one doubles the time to compute every hash, for you and for an attacker trying billions of guesses. Second, a built-in salt: every hash includes 16 random bytes, so two users with the same password get different hashes and precomputed rainbow tables are useless. The salt and cost are stored inside the hash string itself, which is why verifying needs only the password and the hash, never a separate salt column.

Choosing a cost factor

Pick the highest cost your login endpoint can afford: a common target is 100 to 250 ms per hash on your production server. Cost 10 is the default in most libraries and OWASP recommends a minimum of 10; many teams now use 11 or 12. Measure on the real hardware rather than copying a number, because a cost that takes 80 ms on a laptop can take 300 ms on a small cloud instance under load.

This page runs bcrypt in JavaScript inside your browser, which is noticeably slower than the native bcrypt bindings a server uses, so the timing shown after hashing is an upper bound. Costs above 12 are allowed but can take many seconds here. Existing hashes keep working when you raise the cost: verify at login with the old hash, then rehash and store the new one.

$2a$, $2b$ and $2y$ prefixes

The prefix identifies the bcrypt revision. $2a$ is the original widely deployed version. $2b$ was introduced by OpenBSD in 2014 to fix a bug where passwords longer than 255 bytes wrapped around; it is what most current libraries write by default. $2y$ comes from PHP's crypt_blowfish, which used it to mark hashes from its corrected implementation after a 2011 bug, flagged as $2x$, mishandled characters with the high bit set.

For passwords under 72 bytes, $2a$, $2b$ and $2y$ produce identical output, and most modern libraries verify all three. This tool computes the hash once and lets you choose the label: $2y$ for PHP and Laravel, $2b$ for Node, Python and Go. If a library rejects one prefix, swapping it for an equivalent one is safe.

The 72-byte input limit

bcrypt only uses the first 72 bytes of the password; anything after is silently ignored. Bytes are counted in UTF-8, so a password of emoji or CJK characters reaches the limit with far fewer than 72 characters. The generator warns you when the input exceeds 72 bytes.

In practice this only matters for very long passphrases. Do not work around it by pre-hashing with SHA-256 and feeding raw bytes to bcrypt: a zero byte in the digest can terminate the input early. If you must accept longer inputs, base64-encode the pre-hash first, or use Argon2id, which has no such limit.

bcrypt in Node.js, Python, PHP and Laravel

Node.js: with the native bcrypt package, const hash = await bcrypt.hash(password, 12); and await bcrypt.compare(password, hash). The pure-JavaScript bcryptjs package, which this page uses, has the same API and needs no compiler.

Python: import bcrypt; hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12)); then bcrypt.checkpw(password.encode(), hashed).

PHP: $hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]); and password_verify($password, $hash). PHP writes the $2y$ prefix. password_needs_rehash() tells you when to upgrade a stored hash to a new cost.

Laravel: Hash::make($password) and Hash::check($password, $hash). The cost is set by BCRYPT_ROUNDS in .env (default 12 in current versions).