Bcrypt Generator: Hash and Verify Passwords

How to use the bcrypt hash generator

1. Pick Hash a password or Verify against a hash.
2. Type the password. In hash mode choose a cost factor from 4 to 12; in verify mode paste the full bcrypt hash.
3. Leave the salt empty to get a fresh random salt each time, or enter 22 salt characters to reproduce a known hash.
4. Click Run. Cost 10 takes well under a second in a modern browser; cost 12 takes a few times longer.

How bcrypt works

Bcrypt is a password hashing function designed by Niels Provos and David Mazieres in 1999. It is based on the Blowfish cipher and is deliberately slow to resist brute force. A bcrypt hash has four parts: the version ($2b$), a two-digit cost factor, a 128-bit salt written as 22 base64 characters, and a 184-bit hash written as 31 characters, 60 characters in total.

The cost factor sets how many times the expensive key setup is repeated: 2cost rounds. Cost 10 means 1,024 rounds and cost 12 means 4,096. The password is used as a Blowfish key, so only its first 72 bytes count, and the salt makes identical passwords produce different hashes.

Cost factor reference

Choosing the right cost factor balances security and performance. Below is a reference table showing the number of rounds for each supported cost in this bcrypt generator.

In production, aim for a cost that takes roughly 250 milliseconds on your server hardware. Cost 12 is generally a safe starting point for modern web applications.

Verifying a bcrypt hash

Verification does not decrypt anything. The tool reads the cost and salt out of the stored hash, hashes the candidate password with those exact parameters, and compares the two strings. Hashes with the $2a$, $2b$ and $2y$ prefixes are accepted, since they differ only in historic bug fixes that do not affect ordinary passwords.

The comparison accumulates differences over every character instead of stopping at the first mismatch, so it takes the same time wherever the strings differ. Server code should do the same, using the constant-time compare that ships with its bcrypt library.

Common mistakes with bcrypt

Several pitfalls can weaken bcrypt's security if handled incorrectly:

• Truncating long passwords. Bcrypt processes only the first 72 bytes of a password. If users enter longer passphrases, everything beyond byte 72 is silently ignored. Pre-hashing with SHA-256 and encoding the digest as base64 before bcrypt avoids the limit, though it changes the scheme. This tool shows a note whenever your password is cut at 72 bytes.
• Using a low cost factor in production. Cost 4 is useful for testing because it completes almost instantly, but it offers negligible protection against modern GPUs. Never ship cost 4 to production.
• Storing the plaintext alongside the hash. The whole point of hashing is that the original password cannot be recovered. Ensure logs and databases never persist the raw input.
• Confusing $2a$, $2b$ and $2y$. These prefixes mark minor revisions. $2b$ is the current OpenBSD form, $2y$ is the PHP and Apache name for the same algorithm, and $2a$ is the older label.
• Using MD5 or SHA-1 for passwords. Fast general-purpose hashes are not password hashes: they can be tried billions of times per second. Use bcrypt, scrypt or Argon2.

When to use bcrypt

Bcrypt remains one of the most widely deployed password hashing algorithms. It is the default in frameworks like Spring Security, Laravel, and Django (via extensions). Use it whenever you need to store user credentials securely. For new projects where memory-hard functions are preferred, consider Argon2, which won the Password Hashing Competition in 2015. However, bcrypt is still considered secure and well-vetted after more than two decades of use.

If you also need to generate random secrets or tokens for API authentication, tools like the API key generator or password generator complement this bcrypt generator in a typical security workflow.

Worked examples