Bcrypt Password Generator
Generate secure bcrypt password hashes instantly in your browser. Choose your cost factor and hash passwords client-side — completely private and free.
Generate secure bcrypt password hashes instantly in your browser. Choose your cost factor and hash passwords client-side — completely private and free.
bcrypt is a password-hashing function designed by Niels Provos and David Mazières in 1999, derived from the Blowfish cipher. Unlike general-purpose hash functions like SHA-256, bcrypt is deliberately slow — and configurably slow, via a cost parameter — which is exactly the property a password hasher needs. A faster hash function lets attackers brute-force more candidates per second; a slower one limits them.
bcrypt also incorporates per-password salt automatically, eliminating an entire class of attacks based on precomputed rainbow tables. The salt and cost parameter are stored as part of the bcrypt output, so verification needs only the stored hash and the candidate password — no separate salt management. This combination of slowness, salt, and self-contained format made bcrypt the default password hash for two decades and a strong choice today.
Modern alternatives exist. Argon2 won the 2015 Password Hashing Competition and offers memory-hardness in addition to time-hardness. scrypt offers similar properties. For new designs, Argon2id is the recommended choice. bcrypt remains acceptable and widely deployed, particularly in environments where Argon2 is not available.
Storing passwords as plaintext is malpractice. Storing them with a fast hash like SHA-256 is barely better — modern GPUs compute billions of SHA-256 hashes per second, making brute-force attacks against any common password feasible in hours. bcrypt's deliberate slowness shifts the economics: at cost factor 12, an attacker spends roughly 250 ms per candidate password, making brute-force impractical for any non-trivial password.
bcrypt's automatic per-password salt also defeats rainbow table attacks. Two users with the same password produce different bcrypt hashes because their salts differ. Compromising the password database does not let an attacker quickly identify common passwords or precomputed-table hits.
Type a password, choose cost, get the hash.
bcrypt uses a modified Blowfish cipher's key-setup phase, repeated 2^cost times. The cost factor is logarithmic — cost 12 is twice as slow as cost 11, four times as slow as cost 10. This logarithmic scaling lets administrators ratchet up the cost over time as hardware improves, without redesigning the system.
Output format is $version$cost$saltAndHash where saltAndHash is base64-encoded with a custom alphabet. The version is typically $2b$ (the modern variant with the wraparound bug fixed) or $2y$ (PHP-specific, equivalent). The salt is 16 bytes; the hash is 24 bytes; together they encode to 53 characters of custom-base64.
Maximum input length is 72 bytes (Blowfish key length limit). Longer passwords are silently truncated, which is a long-standing bcrypt quirk. Best practice is to either limit password length to 72 bytes or pre-hash with SHA-256 to normalize length before bcrypt.