bcrypt hash generator and verifier

Two halves of one workflow

Every password-based login system does two distinct things with bcrypt: it hashes a password once, at signup or password-change time, and it verifies a password against that stored hash every time the user logs in again. This page gives you both tools together, because testing or debugging an authentication flow usually means moving back and forth between the two.

Generating a hash

Type a password into the generator, choose a cost factor, and click Generate. The result is a full bcrypt hash string — including its embedded salt and cost factor — ready to store in a database column exactly as-is. See our deep dive on bcrypt's built-in salting if you want to understand why the same password produces a different string every time you regenerate it.

Verifying a password against a hash

Paste an existing bcrypt hash (the full string, starting with $2a$, $2b$, or $2y$) into the verifier along with a candidate password, and click Verify. The tool extracts the salt and cost factor embedded in the hash, re-runs bcrypt with the candidate password using those exact parameters, and reports whether the result matches — precisely what a login endpoint does behind the scenes.

What this looks like in real backend code

Most languages expose the same two operations through a bcrypt library. In Node.js, for example, the pattern is:

const hash = await bcrypt.hash(password, 10); at signup, and const ok = await bcrypt.compare(candidate, storedHash); at login. Python's bcrypt and passlib libraries, PHP's built-in password_hash() / password_verify(), and Ruby's bcrypt gem all follow this identical hash-then-compare shape. This tool lets you sanity-check that a value your backend produced (or a value you're about to hardcode into a test fixture) behaves the way you expect, without spinning up a server.

Common reasons verification fails

• Copy-paste truncation — bcrypt hashes are exactly 60 characters long; a shortened hash will never verify.
• Accidentally hashing the password twice, or comparing against a hash of a hash.
• Character encoding mismatches if the password contains non-ASCII characters and different systems normalize them differently.
• Confusing a bcrypt hash with an MD5 or SHA-256 digest — bcrypt hashes always start with $2; a 32 or 64-character hex string is not a bcrypt hash and cannot be verified as one.