Bcrypt Hash Generator

Generate bcrypt-style password hashes with configurable cost factors. Ideal for understanding bcrypt output format and testing password workflows.

Note: True bcrypt uses the Blowfish cipher and requires a server side implementation. This tool generates a SHA-256 based simulation formatted in bcrypt's $2a$ output style for demonstration and learning purposes. For production use, use a server side bcrypt library (e.g., password_hash() in PHP, bcrypt in Node.js).
Cost: - Salt: - Length: - chars

About Bcrypt

Bcrypt is a password hashing function based on the Blowfish cipher. It was designed in 1999 by Niels Provos and David Mazieres. Its key advantage is the configurable cost factor, which makes it resistant to brute force attacks as hardware gets faster.

Bcrypt Hash Format

A bcrypt hash looks like: $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

  • $2a$ - Algorithm identifier (bcrypt)
  • 10$ - Cost factor (2^10 = 1,024 rounds)
  • Next 22 characters - Base64-encoded salt
  • Remaining 31 characters - Base64-encoded hash

Cost Factor Guidelines

  • 10 - Minimum recommended (default in most libraries)
  • 12 - Good balance of security and performance
  • 14+ - High security but slower (suitable for low-traffic systems)
  • Each increment doubles the computation time

Related Tools

Why bcrypt Is Still the Default for Password Hashing

Bcrypt has been the default password-hashing algorithm in production since 1999 because it does three things right: it's adaptive (you can crank up the cost as hardware improves), it has a built-in salt, and its output format is compact and self-describing. New hashes today should still use bcrypt, Argon2id, or scrypt — never raw SHA-256, MD5, or PBKDF2 with low iteration counts.

How bcrypt works

Bcrypt's core is a key-setup function adapted from the Blowfish cipher. The cost parameter (typically 10–14) is an exponent: cost 10 means 2¹⁰ rounds of the key schedule. Doubling the cost doubles the time required to hash. The 22-character salt is generated automatically and embedded in the output. A typical bcrypt hash looks like $2b$12$LQv3c1yqBWVHxkd0LHAkCO... — the prefix tells you the algorithm version and the cost factor.

Choosing a cost factor

Higher cost = stronger hash but slower login. The classic guidance: pick the cost that takes about 250 ms to verify on your production hardware. In 2026, that's typically cost 12 on a single x86 core. Cost 10 is too low for high-value accounts; cost 14 starts to noticeably impact login UX. Re-hash with a higher cost when CPUs get faster.

Common mistakes

  • Truncating the password to 72 bytes. Bcrypt silently ignores anything past byte 72. Pre-hash with SHA-256 if you need to support long passwords.
  • Using the same cost forever. Hashes generated in 2014 at cost 10 are weak by today's standards. Verify-and-rehash on next login.
  • Returning the hash via API. Even though hashes are not reversible, leaking them gives an attacker offline brute-force material. Treat them like secrets.
  • Comparing with string equality. Always use the library's compare() function — it parses the cost/salt out of the stored hash automatically.

When to choose Argon2id instead

For green-field systems, Argon2id (winner of the 2015 Password Hashing Competition) is a stronger default — it's memory-hard, which makes GPU and ASIC attacks much more expensive. Use bcrypt when you need broad library support across older runtimes (Java 8, PHP 5, legacy .NET) or when integrating with an existing user table. See our deep-dive: bcrypt vs Argon2 in 2026.

This generator runs entirely in your browser — your passwords never touch our servers. For storing real user credentials, generate hashes server-side using your language's official library (bcrypt, bcryptjs, BCrypt.Net, etc.).

Frequently Asked Questions

What is the recommended bcrypt cost factor in 2026?

Cost 12 on modern CPUs gives ~250ms verification time, which is the sweet spot. Use 13–14 for high-value applications and re-hash on login when you raise the floor.

Why does bcrypt limit passwords to 72 bytes?

It is a property of the underlying Blowfish key schedule. To support longer passwords, pre-hash with SHA-256 or HMAC and feed the digest into bcrypt.

Should I use bcrypt or Argon2 for new applications?

Argon2id is the modern recommendation. Use bcrypt only when library support or migration constraints require it.

Is my password sent anywhere when I generate a hash here?

No. The hash is computed in your browser using a JavaScript bcrypt implementation. Nothing leaves your device.