Hash and verify passwords with bcrypt. Fully client-side.
Bcrypt is a password hashing function designed specifically to be slow. Unlike fast hashes like SHA-256 or MD5 — which are built for speed and are dangerous for passwords — bcrypt has a tunable cost factor (rounds) that makes it computationally expensive to brute-force. Each increase in cost doubles the time: cost 10 takes ~100ms, cost 12 takes ~400ms, cost 14 takes ~1.6s.
Bcrypt also includes a built-in salt, a random value mixed into each hash. This means the same password produces different hashes every time, defeating rainbow-table attacks. The salt is embedded in the output string, so you only need to store the hash — no separate salt column required.
A bcrypt hash looks like $2a$10$N9qo8uLOickgx2ZMRZoMye.... The parts: $2a$ is the algorithm version, 10 is the cost, and the rest is the salt + hash. For production use in 2026, cost 12 is the common recommendation — fast enough for a web login, slow enough to resist large-scale cracking.
This tool in other languages:
Français:
Générateur bcrypt
Español:
Generador bcrypt
Deutsch:
Bcrypt Generator
Português:
Gerador bcrypt
日本語:
bcrypt ジェネレーター
中文:
Bcrypt 生成器
한국어:
bcrypt 생성기
العربية:
مولد bcrypt
Enter the password and pick a cost factor (higher = slower and more secure). Click Generate hash. The resulting hash (starting with $2a$ or $2b$) includes the algorithm version, cost, salt, and hash — store the whole string in your database.
Bcrypt is deliberately slow — it's designed to take ~100ms per hash, making brute-force attacks economically infeasible. SHA-256 can compute billions of hashes per second on a modern GPU. Bcrypt also includes automatic salting, so identical passwords produce different hashes.
Aim for cost 12 as a 2026 default — about 250ms per hash on modern hardware. Increase every couple of years as hardware gets faster. 10 is too fast now; 14+ may feel laggy on login but is appropriate for high-security contexts. Never go below 10 in production.
Use the Verify tab: enter the password and the existing hash. The tool checks if they match. This is what your backend does on login — compare the submitted password against the stored hash using bcrypt's compare function, not plain string comparison.
Bcrypt — widely supported, battle-tested since 1999, CPU-hard. Scrypt — memory-hard, resists GPU attacks better. Argon2 — the winner of the 2015 Password Hashing Competition, both memory-hard and CPU-hard, considered state of the art. All three are secure; Argon2 is preferred for new projects where the library is available.
Bcrypt silently truncates passwords at 72 bytes. If your users have very long passphrases, only the first 72 bytes count. In 2024 Okta disclosed this contributed to a security issue. Mitigation: pre-hash long inputs with SHA-256 before bcrypt, or use Argon2 which has no such limit.