Bcrypt Hash Generator
Hash a password with Bcrypt or verify a hash.
Overview
The Bcrypt hash generator computes a password digest you can drop straight into a user table, and also verifies a plaintext password against an existing Bcrypt hash. Pick a cost factor, type a password, and the output is the familiar $2b$12$... string used by countless web frameworks.
Backend developers building or auditing login systems, security engineers checking that an old hash is still strong enough, and CTF players generating verification fixtures all reach for an online Bcrypt hash tool. The cost factor is the single most important knob — it lets you trade login-time CPU for cracking resistance.
How it works
Bcrypt, published by Provos and Mazières in 1999, is built around a modified Blowfish key schedule called EksBlowfish. The cost factor is an exponent: cost c runs 2^c key-setup iterations, so cost 12 is 4096 iterations and cost 14 is 16 384. A 16-byte random salt is generated per hash. The encoded string is $2b$<cost>$<22-char base64 salt><31-char base64 hash> — the salt and cost are embedded so verification needs only the stored string and the candidate password. Bcrypt truncates inputs at 72 bytes, which is the single biggest footgun: long passphrases are silently shortened.
Examples
Password: hunter2
Cost: 12
Output: $2b$12$KIXxQrR6FvAo7Y/m6vQy.eHt8Q5g9...
Password: correct horse battery staple
Cost: 10
Output: $2b$10$abcde.../...
Verify "hunter2" against $2b$12$KIXxQrR6FvAo7Y/m6vQy.e...
Output: Match
Verify "wrong" against $2b$12$KIXxQrR6FvAo7Y/m6vQy.e...
Output: No match
FAQ
What cost factor should I use?
OWASP recommends a cost of 10 as a minimum and 12+ where you can afford it. Aim for roughly 250 ms per hash on your production hardware, and bump the cost as machines get faster.
Why is my long password being ignored after the 72nd byte?
Bcrypt was designed for the 8-character passwords of the late 1990s and silently truncates at 72 bytes. For passphrase use cases, pre-hash with SHA-256 and base64-encode before feeding into Bcrypt, or pick Argon2id instead.
Are $2a$, $2b$, and $2y$ interchangeable?
Functionally yes, with one historical caveat: $2a$ had an unsigned-char bug fixed in $2y$ (PHP) and $2b$ (OpenBSD). Modern libraries handle all three correctly; new hashes should use $2b$.
Can the same password produce different hashes?
Yes — the random salt means every call produces a different output, even for identical passwords. Verification re-derives the salt from the stored hash.