Bcrypt Generator and Checker

How to hash a password with bcrypt

1. Under Hash a password, type the Password. A counter shows its length in UTF-8 bytes and warns you when it goes over 72 bytes.
2. Choose the Cost factor (4–14). The line below shows the number of rounds, for example 10 → 2^10 = 1,024 rounds.
3. Click Generate hash. A progress bar follows the work, and the page stays usable while it runs. When it is done, the tool shows the time taken and the Bcrypt hash, ready to copy.
4. The hash is split into its parts: Version, Cost, Salt (22 characters) and Hash (31 characters).

To check a password against a hash, type the password, paste the hash (the one you just generated is filled in automatically) and click Check password. The result says whether they match. Tick Hide passwords to mask both password fields.

The hashing runs in your browser with the bcryptjs library, loaded only when you first need it. No password or hash is sent anywhere.

How bcrypt works

bcrypt (Provos and Mazières, 1999) is a password hashing function built on the Blowfish cipher. Unlike SHA-256, it is deliberately slow, and its slowness is adjustable: the cost factor is a power of two, so each +1 doubles the work. A cost of 10 means 1,024 iterations of the expensive key setup; a cost of 12 means 4,096. That slowness barely matters when a user logs in, but it makes brute-forcing a stolen database far more expensive.

A hash such as $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy reads as follows:

• $2b$: the version. $2a$ and $2y$ (PHP) are compatible and can be checked here; $2x$ marks hashes from an old buggy implementation and is refused.
• 10: the cost factor.
• The next 22 characters: a random 128-bit salt, in bcrypt’s own Base64 alphabet (./A-Za-z0-9).
• The last 31 characters: the 184-bit result.

Because the salt is random and stored in the hash, hashing the same password twice gives two different hashes, and both verify correctly. That is also why you check a password with a verify function instead of comparing hashes.

Choosing the cost

Pick the highest cost your server can afford while keeping logins fast, typically around a quarter of a second per hash. OWASP recommends a minimum cost of 10 for bcrypt. Browsers run bcrypt in JavaScript, which is several times slower than a native server implementation: from a cost of 12 the tool warns that hashing can take one to several seconds, and each extra step doubles the time. The work is split into short slices, so the page does not freeze.

For new systems, OWASP now prefers Argon2id, with bcrypt still acceptable where Argon2id is not available.

The 72-byte limit

bcrypt only uses the first 72 bytes of the password; everything after is silently ignored. Bytes are not characters: an accented letter takes 2 bytes in UTF-8 and an emoji takes 4. Two long passwords that share their first 72 bytes produce the same hash. The byte counter warns you when a password is too long. Some systems pre-hash long passwords (for example with HMAC-SHA256, then Base64) before bcrypt; if you do this, never pass raw binary digests, because a zero byte would end the password early in many implementations.