Generate and Verify Bcrypt Password Hashes
Bcrypt is a password hashing function built specifically to make stored passwords hard to crack. Ordinary fast hashes are the wrong tool for passwords, because an attacker who steals a database can try billions of guesses per second against them. Bcrypt is deliberately slow and, crucially, adjustable in how slow it is, so it stays expensive to attack even as hardware improves. This tool generates a bcrypt hash from a password you enter and also verifies a password against an existing hash, which covers both sides of what you do in a real login system: storing a hash when a user signs up, and checking a hash when they log in.
A bcrypt hash has a fixed, self-describing shape sixty characters long. It begins with a version marker, then the cost, then the salt and digest packed together. In the common form the string starts with a dollar sign, the version identifier, another dollar sign, a two-digit cost, another dollar sign, and finally a run of characters that encodes a twenty-two-character salt followed by a thirty-one-character digest. The cost is the work factor, and it is an exponent: raising it by one doubles the amount of computation required, which is why a small number has a large effect. This tool lets you choose a cost between four and fourteen, where a low value is fast and suited to quick tests and a higher value is slow and suited to protecting real credentials. Because the salt and cost travel inside the hash itself, a verifier needs nothing but the stored hash and the candidate password to check a match.
Two behaviours of bcrypt often surprise newcomers, and both are easy to see with this tool. The first is that the salt is random, so hashing the same password twice produces two completely different sixty-character strings. This is intentional and good: it means two users with the same password get different hashes, and an attacker cannot tell from the stored values that the passwords are identical. Verification still works because the salt is embedded in the hash, so the verifier re-applies the exact same salt when it recomputes. The second is that bcrypt truncates the password at seventy-two bytes, silently ignoring anything beyond that length. A very long passphrase is therefore only as strong as its first seventy-two bytes, which is worth knowing before you assume extra length adds security.
These properties map onto concrete tasks. A developer building a sign-up flow uses the generator to see exactly what a stored hash looks like and to choose a cost that balances security against the response time of a login request. An engineer debugging an authentication bug pastes a stored hash and the password a user reported, then uses verify to confirm whether the mismatch is in the hashing or somewhere else in the flow. A tester seeding a database with sample accounts generates hashes at a low cost so the test suite runs quickly, while production uses a higher cost. A reviewer checking a security change reads the cost embedded in a sample hash to confirm the team raised the work factor as intended rather than leaving a weak default in place.
A few points keep you safe. Choose the cost by timing it on your real hardware and aim for a login that takes a noticeable fraction of a second, then raise the number over the years as machines get faster, since each increment doubles the effort an attacker must spend. Never treat bcrypt as reversible: there is no decode, and the only way to check a password is to hash the candidate with the stored salt and compare, which is exactly what verify does. Do not paste a genuine production password or a live hash into any online tool you do not control; this tool runs entirely in your browser and uploads nothing, but the safe habit is to use throwaway values when demonstrating. Everything here happens locally, so the passwords and hashes you enter never leave your own device.