Security

Bcrypt Hash Generator

Generate Bcrypt-style hashes for passwords with adjustable cost factor. Useful for testing, fixtures and comparing implementations. Everything runs in your browser.

Instant🔒In your browserNo signup
Live
10

Cost 10: ~100 ms per hash (modern server)

Why Bcrypt instead of SHA

SHA-256 is fast by design: 100 million hashes per second on a GPU is routine. That's an advantage when hashing files for integrity checks, but a problem for passwords: an attacker can try billions of candidates per second against a leaked database.

Bcrypt solves this by being intentionally slow. Its cost factor (also called work factor or rounds) controls how many iterations of a modified Blowfish algorithm run: 2^cost. With cost 10 that's 1024 iterations; with cost 12 it's 4096. Each increment doubles the time.

What a Bcrypt hash looks like

The format is $2a$10$abcdefghijklmnopqrstuv1234567890abcdefghijklmnopqrstu:

  • $2a$ (or $2b$, $2y$): version identifier.
  • 10: the cost factor.
  • Next 22 characters: the salt (16 bytes in modified Base64).
  • Final 31 characters: the hash (24 bytes in modified Base64).

All this travels with the hash. So when verifying a password, you don't need to store the salt separately: bcrypt reads it from the hash itself.

Cost factor: how to pick it

The cost factor is a tradeoff between security and login latency. Rough 2026 guidance:

  1. Cost 8-9: obsolete. Legacy data only.
  2. Cost 10: minimum acceptable. ~100 ms per hash on a modern server.
  3. Cost 12: recommended for new production. ~400 ms.
  4. Cost 13-14: high security. ~1-2 seconds per hash.
  5. Cost 15+: excessive for interactive login (annoying latency).

Good practice: bump the cost factor every 1-2 years. The most practical way is to rehash a user's password on login: if the current cost is below your target, compute the new hash and persist it.

Salt and rainbow-table resistance

Each bcrypt hash includes a random 16-byte salt generated at hash time. As a result, hashing the same password twice produces different hashes. That defeats rainbow-table attacks (precomputed hash-to-password tables): the attacker would have to build a rainbow table per salt.

Bcrypt vs argon2id vs scrypt

  • Bcrypt (1999): widely adopted, stable libraries everywhere. Limited: only 72 password bytes and not ASIC-resistant.
  • scrypt (2009): adds memory requirements, making ASICs harder. Used in some cryptocurrencies and in LastPass.
  • argon2id (2015): winner of the Password Hashing Competition. Configurable in CPU, memory and parallelism. The current OWASP recommendation for new applications.

If you're starting fresh, use argon2id. If your stack has bcrypt baked in for years, keeping it at cost 12+ is perfectly safe today.

Common Bcrypt mistakes

  • Using it for non-password hashing. Bcrypt isn't a file or identifier hash — use SHA-256 for those.
  • Not capping password length below 72 bytes. Bcrypt silently truncates at 72 bytes. Validate length first.
  • Cost factor too low. Cost 6 or 7 was reasonable 15 years ago. Today it cracks in hours.
  • Rolling your own. Never implement bcrypt yourself: use your language's official library. This generator is for testing only.

FAQ

What is Bcrypt?

A password-hashing function. Intentionally slow to make brute force expensive even with GPUs.

Which cost factor?

In 2026, 12 minimum and 13-14 recommended. Each increment doubles the time.

Bcrypt or argon2?

Argon2id is more modern and hardware-resistant. Bcrypt remains acceptable; argon2id is preferable for new builds.

Is it safe in the browser?

For testing, yes. In production, hash on the server with your language's official library.

Was this generator useful?