🔒 Processed entirely in your browser. Your password never leaves your device.
Bcrypt hash appears here
Enter a password and click Hash to begin// hash and verify passwords with bcrypt — browser-based
Generate and verify bcrypt password hashes in the browser. Configurable cost factor, salt preview, hash anatomy breakdown, timing info. Free, no signup, your password never leaves your device.
Bcrypt hash appears here
Enter a password and click Hash to beginType a password and choose a cost factor (10–12 recommended for production). Higher cost means more iterations and longer computation — but significantly harder to crack.
Click "Hash Password". The hash is computed in your browser using a pure-JS bcrypt implementation. The timing shows how long it took at the chosen cost factor.
Switch to the Verify tab. Paste a bcrypt hash and enter the original password — the tool confirms whether they match, using the same secure comparison logic.
Bcrypt is designed to be slow. Unlike MD5 or SHA-256, which can run billions of times per second on a GPU, bcrypt is intentionally computationally expensive. The cost factor lets you tune this — doubling cost = double the computation. As hardware gets faster, you increase the cost to maintain attack resistance.
A bcrypt hash contains three parts: the algorithm version ($2b$), the cost factor ($12$), and a 53-character string combining a 22-character salt with the 31-character hash output — all encoded in a modified Base64 alphabet. The hash is 60 characters total. Every call produces a different hash due to the random salt, but all verify correctly.
For production user authentication, cost factor 12 is the current standard recommendation. At cost 12, hashing takes roughly 250ms on a modern server — fast enough for users not to notice, slow enough to make brute-force attacks expensive. Increase by 1 every few years as hardware improves. Never go below 10 for real passwords. The default here is 12.
Bcrypt runs the Blowfish cipher setup routine 2^cost times. At cost 10, that's 1024 iterations. At cost 12, 4096. At cost 16, 65536. This deliberate slowness is the security mechanism — an attacker who steals your password database can only test as many guesses per second as your hardware allows (roughly the same as your server), making offline dictionary attacks impractically slow.
Each call to bcrypt generates a fresh random 16-byte salt, which is mixed into the hash. The salt is stored inside the 60-character bcrypt string, so the verification function can extract it. Two hashes of the same password differ because they used different salts, but both verify correctly against the original password. This prevents rainbow table attacks.
$2a$ is the original bcrypt version. $2b$ fixes a bug in the handling of 8-bit characters in passwords — it is the current correct version produced by OpenBSD and most modern libraries. $2y$ is a PHP-specific variant that is equivalent to $2b$. All three verify correctly against each other in modern implementations. This tool always produces $2b$.
No. All bcrypt computation happens entirely in your browser using a pure-JavaScript implementation. Your password, the generated hash, and the salt never leave your device. The computation is done by your browser's JavaScript engine, not by any remote server. You can verify this by using the tool offline after the page has loaded.
Bcrypt is a one-way function — there is no mathematical way to reverse it. Cracking requires brute-force guessing. At cost 12, even a specialized GPU cracking rig can only test around 5,000–20,000 guesses per second per card (vs billions per second for MD5). A strong password with cost 12 is practically uncrackable. Weak passwords remain vulnerable — bcrypt protects against offline attacks, not weak password choices.
Bcrypt was designed in 1999 by Niels Provos and David Mazières specifically for password hashing. Unlike general-purpose hash functions (MD5, SHA-256) that optimize for speed, bcrypt optimizes for slowness — deliberately consuming CPU cycles through its key setup phase. This property makes bcrypt fundamentally resistant to the GPU-accelerated cracking techniques that have made MD5 and SHA-1 password hashes practically worthless for security.
The cost factor is bcrypt's key innovation. It is stored inside the hash itself ($12$ means cost 12), and the verifier uses the stored cost to perform the same number of iterations. This means you can increase the cost factor over time as hardware improves — old hashes remain verifiable at their original cost, while new hashes use the higher cost. Most authentication libraries support transparent re-hashing: when a user logs in successfully, the old hash is replaced with a new higher-cost hash.
Bcrypt protects your stored passwords if your database is leaked — an attacker who obtains the hash file cannot reverse the hashes or test guesses at GPU speed. However, bcrypt does not protect against: weak passwords (an attacker can still guess password123 quickly), credential stuffing (trying stolen credentials from other sites), phishing, or server-side vulnerabilities that expose passwords before hashing. Password security requires both strong hashing and strong passwords.