Hash any password with bcrypt and verify existing hashes — choose your cost factor, run it in your browser, send nothing to a server.
12~300ms
6 (Fast)10 (Balanced)14 (Slow)
Hashing… this may take a moment for higher cost factors
Bcrypt Hash
Hash Anatomy
Algorithm
Cost Factor
Salt
Hash
Full Length
Verifying…
Advertisement
All hashing runs in your browser via WebAssembly — your password never leaves your device.
Advertisement
Understanding Bcrypt
What Is Bcrypt and Why Use It?
Bcrypt is a password hashing function designed in 1999 by Niels Provos and David Mazières. Unlike general-purpose cryptographic hashes like SHA-256 (which can compute billions of hashes per second on a GPU), bcrypt is intentionally slow and memory-intensive. Its work factor is tunable — meaning you can make it slower as hardware improves, keeping brute-force attacks computationally expensive. It remains one of the three gold-standard password hashing schemes alongside Argon2 and scrypt.
Bcrypt vs SHA-256 vs MD5
MD5 and SHA-256 are cryptographic hashes designed for speed — great for checksums and data integrity, catastrophic for passwords. A modern GPU can compute 10+ billion SHA-256 hashes per second, making dictionary attacks trivial. Bcrypt is limited to ~20 hashes per second at cost 12 on the same hardware — a 500-million-times slowdown. Never store passwords with MD5, SHA-1, or unsalted SHA-256. For other hashing needs, see our Hash Generator.
Understanding the Bcrypt Hash Format
A bcrypt hash looks like $2b$12$SaltSaltSaltSaltSaltS.HashHashHashHashHashHashHashHashH. It encodes everything needed to verify a password: the algorithm version ($2b$), the cost factor (12), a 22-character salt, and a 31-character hash. The salt is automatically generated and embedded — you never need to store it separately, and each hash is unique even for identical passwords.
Choosing the Right Cost Factor
The cost factor (work factor) controls how many iterations bcrypt runs — each increment doubles the computation time. The OWASP recommendation as of 2024 is cost 10 for most applications, with cost 12 for higher security requirements. The goal is to keep hash time around 100ms–300ms on your server hardware — slow enough to thwart brute force, fast enough not to hurt legitimate users. Reassess every two years as hardware improves.
Frequently Asked Questions
Bcrypt is excellent and battle-tested over 25 years, but Argon2id — the winner of the 2015 Password Hashing Competition — is the current OWASP-preferred recommendation for new applications. Argon2id is memory-hard, making GPU and ASIC attacks even more expensive. Bcrypt remains a perfectly secure and widely supported choice, especially in ecosystems (like PHP and Node.js) where library support is mature. Avoid scrypt unless you have specific requirements; its API is more complex and easier to misconfigure.
Yes — most bcrypt implementations truncate input at 72 bytes. Passwords longer than 72 characters produce the same hash as the first 72 characters, which can be a security issue for very long passphrases. If you need to support arbitrarily long passwords, pre-hash the input with SHA-256 (without truncation) and feed the resulting bytes to bcrypt. This is a rare edge case for most applications; the overwhelming majority of real-world passwords are well under 72 characters.
Bcrypt automatically generates and embeds a unique 128-bit salt in every hash. This means two identical passwords produce completely different hashes — which defeats rainbow table attacks and prevents an attacker who sees multiple hashes from knowing two users share the same password. Verification works by extracting the salt from the stored hash and re-running the algorithm with the candidate password to see if the output matches.
Yes — this is a common use case. You can hash a known password, paste the result into your application's verification logic, and confirm it returns a match. You can also take a hash produced by your application, paste the original password into the Verify tab, and confirm the hash is correct. Since all processing is client-side, there is no privacy risk using test credentials. For production passwords, this tool is safe to use since nothing leaves your browser — but best practice is to generate hashes server-side in your application.
A pepper is a server-side secret appended or prepended to the password before hashing — stored in application config or a secrets manager rather than the database. If an attacker obtains a database dump but not the server config, the pepper makes all hashes useless without the secret. Peppering is considered a defence-in-depth improvement on top of bcrypt, not a replacement. It adds complexity (key rotation is non-trivial) so assess whether the threat model justifies it for your application.
