Generate salted bcrypt hashes for passwords and verify plaintext against an existing hash, all in your browser.
Generate salted bcrypt hashes for passwords and verify plaintext against an existing hash, all in your browser. Generate salted bcrypt hashes for passwords and verify plaintext against an existing hash, all in your browser.
Generated bcrypt hash
Background
What bcrypt is and why it matters
bcrypt is an adaptive password hashing function designed by Niels Provos and
David Mazieres in 1999. Unlike fast digests such as MD5 or SHA-256, bcrypt
deliberately costs CPU time: each hash runs the Blowfish cipher through a
configurable number of rounds, and the work doubles with every increment of
the cost factor. This slowdown is what makes offline dictionary and
brute-force attacks expensive. A correct bcrypt implementation also embeds a
random 128-bit salt inside the output string, so two hashes of the same
password are always different and rainbow tables are useless against it.
How to read a bcrypt hash
A bcrypt hash looks like $2b$12$e0.6kJ8a5X8u5Yp3qR5E0e9dF4z3W2c1v0b9n8m7l6k5j4h3g2f1. The
parts after the leading dollar signs carry the algorithm version, the cost,
and the salt:
$2b$ -- the algorithm revision. $2a$ and $2y$ are older variants with
subtle handling differences for the 8-bit sign bug; $2b$ is the current
recommendation and what bcryptjs emits.
12 -- the cost factor. 2^12 = 4096 rounds of the key schedule. Each +1
doubles the time; 10-12 is a reasonable default for interactive login,
while 12-14 suits stored credentials.
The remaining 53 characters hold a 22-character (128-bit) base64 salt plus
a 31-character (184-bit) checksum. The whole string is a self-contained
record: the verifier reads the version, cost, and salt back out of the hash
and re-runs the derivation to compare.
How to use this tool
Type a password into the input, pick a cost factor, and press Hash. The
generated hash appears in the output box and is also placed into the verify
field. To check an existing hash, paste it into the verify field and type
the candidate password in the input: the page compares immediately and shows
a green check or a red cross. Because the comparison is done with
bcrypt.compareSync, it never reveals how close a wrong guess was -- every
attempt is hashed in full before the result is decided.
Security notes and limitations
bcrypt truncates input to 72 bytes: longer passwords are silently cut, so
two passwords sharing the first 72 bytes compare equal. If you need longer
inputs, pre-hash with SHA-256 (hex-encoded) and bcrypt that digest instead.
Bcrypt is a deliberate memory-light algorithm -- it resists GPU arrays less
well than memory-hard designs such as Argon2 or scrypt, but its 4 KB table
and 64-byte state still make cheap ASIC cracking unattractive. For brand-new
systems Argon2id is often a better choice; bcrypt remains an excellent,
widely supported option for legacy compatibility and for cases where the
runtime cannot provide Argon2. This page runs entirely in your browser: the
password and the hash never leave your device, and you can inspect the code
path (MIT/BSD bcryptjs) bundled in public/assets.
Frequently asked questions
Why does the same password produce a different hash every time?
A random 128-bit salt is generated for each hash and embedded in the output. The verifier re-reads the salt from the hash, so correctness is unaffected, but identical inputs never yield identical outputs.
What cost factor should I use?
For interactive logins, 10-12 is a good default. For stored credentials you may want 12-14. Higher costs are safer but slower; pick the largest value your server can afford per login.
Is bcrypt still recommended in 2026?
Yes. bcrypt remains widely deployed and is considered safe when used with a cost of 10+. For brand-new systems, memory-hard Argon2id or scrypt are often preferred, but bcrypt is a fine, battle-tested choice, especially where those are unavailable.
Why is bcrypt slower than SHA-256?
That is the point. SHA-256 is designed to be fast, which lets attackers try billions of guesses per second. bcrypt's expensive key schedule and salt force attackers to spend real time per guess, making offline attacks impractical.
What does the 72-byte limit mean for my passwords?
bcrypt ignores everything past byte 72. Two passwords longer than 72 bytes that share the same prefix will verify identically. To support longer secrets, hash them with SHA-256 first (as hex) and bcrypt the digest.
Is my password sent to a server?
No. Everything runs locally in your browser with the bundled bcryptjs library. You can disconnect from the network after the page loads and it will still work.