Bcrypt Hash Generator & Checker
Create a salted bcrypt hash for a password with the cost factor you choose, or paste an existing hash to check whether a password matches it. Hashing runs on your device and the password never leaves the page.
How to use the Bcrypt Hash Generator & Checker
- Generate tab: type the password and choose a cost factor. 10 to 12 is typical for web logins.
- Pick the prefix: $2b$ is the current standard, $2a$ suits older libraries and $2y$ is what PHP's password_hash() writes.
- Press Generate hash and copy the 60-character result into your database or config.
- Verify tab: paste a bcrypt hash and type a password, then press Verify password to see whether they match.
- Check the breakdown under the hash to see its version, cost and salt.
Why bcrypt instead of MD5 or SHA-256 for passwords?
General-purpose hash functions such as MD5 and SHA-256 are designed to be fast. That is perfect for checksums, but terrible for passwords: a single modern GPU can try billions of MD5 or SHA-256 guesses per second, so a leaked table of unsalted hashes falls to dictionary attacks within hours. Identical passwords also produce identical hashes, which reveals reused passwords and makes precomputed rainbow tables effective.
bcrypt, designed by Niels Provos and David Mazières in 1999, fixes both problems:
- Salted: every hash contains its own random 16-byte salt, so the same password never gives the same hash twice and precomputed tables are useless.
- Slow on purpose: the cost factor sets the number of key-expansion rounds to 2cost. Raising the cost by one doubles the work, so you can keep pace with faster hardware simply by increasing it.
- Memory-hungry enough to annoy GPUs: the Blowfish state (4 KB of S-boxes) is constantly rewritten, which makes bcrypt much less efficient on GPUs than plain SHA-256.
Anatomy of a bcrypt hash
A bcrypt string is always 60 characters. For example, the password password hashed with cost 10 and the salt below gives $2b$10$N9qo8uLOickgx2ZMRZoMye8fOsiTWZqYtkxvXkKm8BMzjT7t/vIdq (paste it into the Verify tab to try):
| Part | Example | Meaning |
|---|---|---|
| Version | $2b$ | Algorithm identifier ($2a$, $2b$ or $2y$) |
| Cost | 10$ | log2 of the number of rounds: 210 = 1,024 |
| Salt | N9qo8uLOickgx2ZMRZoMye | 22 characters = 128-bit random salt |
| Checksum | 8fOsiTWZqYtkxvXkKm8BMzjT7t/vIdq | 31 characters = 184-bit result |
bcrypt uses its own Base64 alphabet, ./A-Za-z0-9, which differs from standard Base64. Because the salt and cost are stored in the hash, a login check only needs the stored hash and the password the user typed.
Cost factor and work
| Cost | Rounds | Relative work | Typical use |
|---|---|---|---|
| 4–7 | 16–128 | 1/64 – 1/8 of cost 10 | Unit tests only |
| 10 | 1,024 | 1× | Default in many libraries (Node bcrypt, Spring Security, PHP) |
| 12 | 4,096 | 4× | A common choice for new web applications |
| 14 | 16,384 | 16× | High-value accounts where slower logins are acceptable |
Benchmark on your own production hardware and pick the highest cost that keeps a login comfortably fast. When users log in, you can rehash their password with a higher cost and store the new hash.
Using bcrypt in code
- PHP:
password_hash($pw, PASSWORD_BCRYPT, ['cost' => 12])andpassword_verify($pw, $hash). - Node.js:
await bcrypt.hash(pw, 12)andawait bcrypt.compare(pw, hash)(bcrypt or bcryptjs packages). - Python:
bcrypt.hashpw(pw.encode(), bcrypt.gensalt(12))andbcrypt.checkpw(pw.encode(), hash). - htpasswd:
htpasswd -nbB -C 10 user passwordwrites a $2y$ bcrypt entry for Apache basic auth.
Frequently asked questions
Why does the same password give a different hash every time?
bcrypt adds a random 128-bit salt to every hash and stores it inside the result (the 22 characters after the cost). Two users with the same password therefore get different hashes, and precomputed rainbow tables are useless. To check a password you hash it again with the salt taken from the stored hash, which is what the Verify tab does.
Which cost factor should I use?
Choose the highest cost your server can afford while keeping a login under roughly 100 to 300 milliseconds. Cost 10 is the default in many libraries; 12 is a common choice on modern hardware. Each step up doubles the time for you and for an attacker. The estimates in the tool are measured in this browser, and servers are usually faster.
What is the difference between $2a$, $2b$ and $2y$?
They are the same algorithm with different version labels. $2b$ was introduced by OpenBSD in 2014 to fix a length bug in its own code, and $2y$ marks hashes from PHP's fixed crypt_blowfish. For passwords up to 72 bytes all three produce the same checksum, so most libraries accept any of them.
Why is bcrypt limited to 72 bytes?
bcrypt feeds the password into the Blowfish key schedule, which uses at most 72 bytes (including a terminating zero byte). Anything after that is ignored, so two long passwords that share their first 72 bytes produce the same hash. Note that characters outside basic Latin take 2 to 4 bytes in UTF-8.
Is it safe to enter a real password here?
The hashing happens entirely in your browser with JavaScript; nothing is uploaded or stored. Still, for production secrets it is good practice to generate hashes on the server or machine where they are used.
Can a bcrypt hash be decrypted?
No. bcrypt is a one-way function. The only way to recover a password is to guess candidates and hash each one with the stored salt and cost, which bcrypt deliberately makes slow.
Should I use bcrypt or Argon2?
Both are good choices. OWASP currently recommends Argon2id first, then scrypt, with bcrypt (cost 10 or more) as a sound option for existing systems. bcrypt is supported almost everywhere, including PHP, Node.js, Python, Ruby, Java and Go.