Bcrypt Generator & Verifier

bcrypt is the password-hashing algorithm that has protected login systems since 1999, and it is still a recommended default today. Unlike general-purpose hashes like SHA-256, bcrypt is deliberately slow and includes a built-in salt, which is exactly what you want when storing passwords. This tool lets you generate bcrypt hashes and check a password against an existing hash — all in your browser.

Why not just use SHA-256 for passwords?

Fast hashes are the wrong tool for passwords. SHA-256 is designed to be fast, so an attacker who steals your database can try billions of guesses per second against it. bcrypt is designed to be slow and tunable: a "cost factor" controls how much work each hash takes. As hardware gets faster, you raise the cost — the algorithm keeps pace with attackers instead of falling behind.

Anatomy of a bcrypt hash

A bcrypt hash looks like `$2b$10$N9qo8uLOickgx2ZMRZoMy...`. It packs four things into one string:

- `$2b$` — the algorithm version - `10` — the cost factor (2¹⁰ = 1024 key-expansion rounds) - the next 22 characters — the random salt - the final 31 characters — the actual hash

Because the salt is stored inside the string, you never manage salts separately. That is why the same password hashed twice produces two different outputs, yet verification still works — the verifier reads the salt back out of the stored hash.

Choosing a cost factor

The cost factor is a security-versus-speed dial. 10 is a common default; 12 is typical for higher-security systems. Every increment doubles the time to compute a hash — so cost 12 is four times slower than cost 10. Pick the highest cost your login flow can tolerate (roughly 100–250 ms per hash is a good target on server hardware).

Verifying a password

To check a login, you never "decrypt" a bcrypt hash — that is impossible by design. Instead you take the password the user typed, hash it with the salt embedded in the stored hash, and compare. This tool's Verify tab does exactly that: paste a hash and a candidate password and it reports match or no match.

Limitations to know

- bcrypt only uses the first **72 bytes** of the input. For long passphrases, pre-hash with SHA-256 first. - For brand-new systems, **Argon2id** is the current state of the art and worth considering. bcrypt remains a safe, widely-supported choice. - Never hash passwords on the client in a real login system — do it server-side. This browser tool is for development, testing, and learning.