Bcrypt Hash Generator

About Bcrypt Hash Generator

bcrypt is a hash function built specifically for storing passwords. Unlike fast hashes such as MD5 or SHA-256, it carries a cost factor that sets how slow the computation is. This tool hashes a password with a fresh salt ($2b$…) or verifies which password matches an existing hash.

The result is a 60-character string of the form $2b$10$…: a version tag ($2b), a cost factor (10), a 22-character base64 salt, and a 31-character base64 digest, all on one line. Because the salt lives inside the string, you don't store it separately to verify later. bcrypt isn't in Web Crypto, so it's implemented in plain JS, and the heavy computation runs in a web worker to keep the page responsive.

The cost factor is an exponent: 10 vs 12

A cost factor c means the internal key setup runs 2^c times, so every increase of one doubles the work. Cost 10 is 2^10 = 1,024 rounds, 12 is 2^12 = 4,096 (four times as much), and 14 is 2^14 = 16,384 (sixteen times). This tool allows 4 to 14 and defaults to 10; 4 is the floor at which it stays responsive on a browser's main thread.

The right cost depends on your hardware. OWASP recommends a work factor of 10 or more for legacy systems that must use bcrypt. A common target is to tune it so a login check takes roughly 0.25–0.5 seconds on your server. Raising the cost slows an attacker working on leaked hashes by the same factor, but it also slows every real login, so push it as high as your server can bear.

You can raise the cost of stored hashes later: the next time a user logs in, re-hash the password they typed at the higher cost and replace the stored value. That upgrade path is why the original paper (Provos & Mazières, 1999) called bcrypt "future-adaptable."

The 72-byte limit: long passwords and UTF-8

bcrypt only uses the first 72 bytes of a password; anything past that is silently ignored. The unit is bytes, not characters. ASCII is one byte per character, but many scripts are not: an emoji or a CJK character is 3–4 bytes in UTF-8, so a password made of such characters is truncated well before 72 characters. This tool warns you when your input exceeds 72 bytes.

That limit became a real vulnerability once. In October 2024 Okta disclosed that its AD/LDAP delegated authentication built a cache key by concatenating userId + username + password and running bcrypt on it. When a username was 52 characters or longer, the password was pushed past the 72-byte boundary and ignored, so under specific conditions any password could pass. The lesson: never prepend other data before feeding a password to bcrypt.

If you must fully incorporate a long password or passphrase, you can pre-hash before bcrypt, but carefully. OWASP notes plain pre-hashing is dangerous because of NULL bytes and "password shucking," and recommends wrapping it as bcrypt(base64(hmac-sha384(password, pepper))). For a new system, it's cleaner to use Argon2 and skip the workaround.

$2a vs $2b: why there's a version letter

The $2a$, $2b$, $2y$ prefix is the algorithm version. $2a is the 1999 original; in 2011 a bug in how the OpenBSD implementation handled 8-bit characters led to the fixed $2b. $2y was PHP's marker for the same fix and is effectively identical to $2b. This tool generates $2b and, when verifying, preserves the original hash's version letter for the comparison.

Because the bcrypt string format is standardized, hashes made in other stacks (PHP, Node's bcrypt, Python's passlib) verify here, and hashes made here verify there.

Same password, a different hash each time

Each time you generate, a fresh 16-byte random salt is created, so the same password yields a different hash every time. That's correct and in fact necessary: the salt makes two users with the same password get different hashes and defeats precomputed lookup tables (rainbow tables).

Verification extracts the salt and cost from the hash string, re-hashes the entered password under the same parameters, and compares with a constant-time check that reduces timing side channels. So without knowing anything else, a password plus a hash is enough to tell whether they match.

Worked examples

How to use it

1. In the generate tab, enter a password and pick a cost (4–14).
2. Generate to get a $2b$… hash with a fresh salt.
3. In the verify tab, enter a password and an existing bcrypt hash to check for a match.
4. Copy the result into your database or code.

Key terms

Cost / work factor

An exponent: the internal setup runs 2^cost times. Each increase of one doubles the time.

Salt

A per-hash 16-byte random value. bcrypt stores it inside the hash string.

72-byte limit

The maximum number of password bytes bcrypt uses; the rest is ignored.

Frequently asked questions

Related guides

• How Password Storage Works: From Plaintext to Argon2