Bcrypt is the most widely-used password hashing function in production — most web frameworks default to it, most security guides recommend it, and most stored-password breaches you read about involve hashes that bcrypt produced. This playground gives you a browser-side place to experiment with bcrypt’s behaviour: generate hashes at different cost factors, verify candidate passwords against existing hashes, see what the output format looks like.
It is not a production password hashing tool. The notes throughout this page repeat that because client-side password hashing is one of those security mistakes that looks reasonable until you think it through; the box at the top of the form makes the same point.
How bcrypt works
Bcrypt is based on the Blowfish cipher, designed in 1999 by Niels Provos and David Mazières specifically for password hashing. The key properties:
- One-way. Given a hash, you can verify a candidate password but you cannot derive the original.
- Salted. Every hash includes a random 16-byte salt, so the same password produces a different hash each time. Defeats rainbow-table attacks.
- Tunable cost. A cost factor (4-14 in this tool, up to 31 in the spec) controls how many iterations bcrypt runs. Each step roughly doubles the time, letting you tune the cost as hardware gets faster.
The hash format is $2a$<cost>$<salt><digest> — exactly 60 characters. The salt and digest portions use a base64 variant; the algorithm prefix and cost are plain text.
The cost factor explained
Cost 10 takes ~100ms on a 2020-era laptop. Each step doubles:
| Cost | Time on 2020 laptop | Use |
|---|---|---|
| 4 | ~5ms | Test code, tutorials |
| 8 | ~25ms | Low-traffic sites with weak threat model |
| 10 | ~100ms | Educational baseline (default here) |
| 12 | ~400ms | 2026 production minimum |
| 14 | ~1.6s | High-value accounts |
Production systems pick the highest cost the user-facing latency budget tolerates. ~250-500ms during login is the practical sweet spot for most web apps; longer makes the login feel sluggish, shorter doesn’t slow attackers enough.
Example: generating a hash
Type “correct horse battery staple” into the password field. Set cost to 10. Click Generate hash. Output: something like $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy. Copy. Run again — different hash (different salt). Both verify correctly against the original password.
Example: verifying a hash from a database
You’re investigating a database export. A user record contains the bcrypt hash above. Switch to Verify mode. Paste “correct horse battery staple” and the hash. Click Verify. Result: ✓ Match, cost 10, took ~100ms. Try “wrong password” — ✗ No match.
Example: estimating attack time
A determined attacker with one mid-range GPU rig can compute roughly 100,000 bcrypt-cost-10 hashes per second. For an 8-character random alphanumeric password (62^8 = ~218 trillion combinations), the expected time to brute-force is ~35,000 years at that rate. Increasing cost to 12 makes it 4× slower; doubling password length raises the search space by ~218 trillion. This is why bcrypt + a long random password defeats brute-force at any practical scale, but bcrypt + “password123” doesn’t (a few seconds against a dictionary attack).
Common mistakes
Hashing client-side and sending the hash. Defeats the purpose. The hash becomes the password; an attacker sniffing it gets full access. Always send the plain password over TLS to the server, hash there.
Re-hashing an existing bcrypt hash. If your DB column contains hashes and you accidentally hash them again on migration, the result is a hash of a hash — which doesn’t verify against the original password. Migrations that change the hashing strategy need to mark records for re-hash on next login, not bulk re-hash.
Picking cost factor by guessing. Benchmark on your production hardware. The tool’s estimate is a 2020-era reference; a 2026 server CPU is meaningfully faster, mobile is slower. Measure under realistic load before committing to a cost.
Storing the cost separately. The cost is encoded in the hash. Don’t store it as a separate column; you’ll desync it.
What this tool does not do
It doesn’t transmit anything to a server. The bcryptjs library runs entirely in your browser; passwords and hashes never leave your device. (This is also why you can’t use it for production hashing — see the warning at the top.)
It doesn’t compare hash speeds against other algorithms (argon2, scrypt). For modern systems, argon2id is generally preferred over bcrypt where available; bcrypt remains popular because of inertia and ecosystem support.
It doesn’t crack hashes. There’s no built-in dictionary or brute-force mode. For real password cracking (audit, recovery), use hashcat or john-the-ripper with a proper wordlist on hardware suited to the task. For general-purpose non-password hashing (file fingerprints, message digests), the hash generator produces SHA-256/384/512; bcrypt is deliberately slow and the wrong tool for those.