100% Client-Side

Bcrypt Hash Generator

Hash passwords with bcrypt — configure cost factor, verify hashes

Free Client-Side No Login No Storage
Loading tool...
Random Password Generator Generate strong, cryptographically secure passwords — customizable length and charset SHA-256 Hash Generator Generate SHA-256 cryptographic hashes instantly — Hex or Base64 output Hash Comparator & Verifier Compare and verify hash values — MD5, SHA-256, SHA-512 and more

How to Use the Bcrypt Hash Generator

  1. Enter the password you want to hash.
  2. Choose a cost factor (10-12 recommended for production).
  3. Click Hash. Copy the bcrypt hash.
  4. Use Verify to check if a password matches a stored hash.

Why bcrypt for passwords?

Unlike SHA-256 or MD5, bcrypt is specifically designed for password hashing. It is intentionally slow (configurable via the cost factor) and includes a random salt automatically, making rainbow table attacks and brute-force attacks impractical.

Cost factor guide: 10 = ~100ms, 12 = ~400ms, 14 = ~1.5s. Higher is more secure but slower. For most web apps, 10-12 is the right balance.

What is Bcrypt?

Bcrypt is a password hashing function designed specifically for storing passwords securely. Unlike general-purpose hash functions (MD5, SHA-256), bcrypt is intentionally slow — it applies a cost factor that makes brute-force attacks computationally expensive. It also automatically handles salting to prevent rainbow table attacks.

Common Uses

  • Hashing user passwords before storing in a database
  • Verifying passwords by comparing a plaintext attempt against a stored hash
  • Choosing an appropriate cost factor for your server's performance budget

Frequently Asked Questions

What is the bcrypt cost factor?

The cost factor (work factor) determines how many iterations bcrypt performs: 2^cost rounds. Cost 10 = 1,024 rounds, cost 12 = 4,096 rounds. A higher cost means slower hashing (harder to brute-force) but also slower login. Cost 10–12 is standard for most applications.

Can I reverse a bcrypt hash?

No. Bcrypt is a one-way function. The only way to "crack" a bcrypt hash is by trying candidate passwords one by one — which the cost factor makes intentionally slow (e.g., 100 ms per attempt at cost 10).

Why does bcrypt have a 72-character input limit?

The original bcrypt algorithm only processes the first 72 bytes of input. Passwords longer than 72 characters are silently truncated. For very long passwords, pre-hash with SHA-256 before bcrypt if needed.

Notes from this implementation

Cost, salt, and the string you store

The hash button calls bcrypt with the cost selected in the form. The default in this script is 12. The salt is random and is stored inside the result, which looks like $2a$12$... or $2b$12$.... You do not store the salt in a second column. You store that whole string.

Two clicks on the same password produce two different strings. Verification hashes the password with the salt embedded in the stored string and compares. If you “normalize” the hash by trimming what you think is padding, verification will fail for a correct password.

Cost is a server decision

Cost 14 is slow on purpose. Generating it in a laptop browser is fine for a one-off. Generating it on every login, on a tiny server, can be a denial-of-service if an attacker triggers many attempts. Pick the cost your production CPU can afford, then use this page to see the string shape and to check a hash you already stored. The salting guide covers why a single site-wide salt is not this.