Bcrypt Hash & Verify

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.

Built with the BSD-3-Clause bcryptjs library bundled in public/assets. Hashing runs locally; nothing is transmitted.

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.