How to Hash a Password with Bcrypt
Bcrypt is a password-hashing function designed to be slow. It turns a password into a fixed-format string that includes a random salt and a cost factor, so the same password never produces the same hash twice and every guess costs an attacker real time. It has been a standard choice for storing passwords since 1999.
What a bcrypt hash looks like
$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
The string packs everything needed to verify a password later:
| Part | Meaning |
|---|---|
$2b$ |
Algorithm version (2a, 2b, and 2y are compatible) |
10 |
Cost factor: 2¹⁰ = 1,024 rounds of key expansion |
| next 22 characters | The random salt |
| remaining 31 characters | The hash itself |
Because the salt is stored inside the hash, you don't need a separate salt column in your database.
Generate a bcrypt hash
- Open the Bcrypt Hash Generator and stay on Generate.
- Type a password.
- Set the Cost Factor (Rounds). 10 is a good starting point.
- Click Generate Hash and copy the result.
The hashing runs in your browser, so the password never reaches a server. This is useful for seeding a test database, writing a fixture, or checking what your backend should produce.
Verify a password against a hash
Switch to Verify, enter the password and the stored hash, and click Verify Password. You'll see whether it matches.
Verification doesn't "decrypt" anything. Bcrypt reads the cost and salt from the stored hash, hashes the candidate password with them, and compares the result. That's also why two hashes of the same password look different: each one has its own salt.
Choosing a cost factor
Each step up in cost doubles the work. The goal is a hash that takes a noticeable fraction of a second on your server: fast enough for a login, slow enough to make mass guessing expensive.
- Cost 4–8: fine for development and tests, too fast for production.
- Cost 10–12: the common production range. Around cost 10, a hash takes on the order of 100 ms on modern hardware.
- Cost 13–14: higher-security systems that can afford slower logins.
Measure on your own hardware and raise the cost over the years as servers get faster. Existing hashes keep working because each hash records its own cost; you can rehash with the new cost when a user next logs in.
Things bcrypt won't do for you
- Long passwords are truncated. Bcrypt uses only the first 72 bytes of input. Passphrases longer than that don't gain strength past the limit.
- It doesn't stop weak passwords. A slow hash buys time; it doesn't make
password123safe. Pair it with password rules or breach checks. - It isn't for general hashing. For file checksums or data integrity, use a fast hash such as SHA-256 with the Hash Generator.
Using bcrypt in code
Most languages have a mature library:
// Node.js (bcrypt or bcryptjs)
const hash = await bcrypt.hash(password, 10);
const ok = await bcrypt.compare(password, hash);
# Python (bcrypt)
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=10))
ok = bcrypt.checkpw(password.encode(), hashed)
Hashes from these libraries verify in the browser tool and vice versa, since they share the same format.
Summary
Bcrypt stores the salt and cost inside the hash, which makes verification self-contained and every hash unique. Use a cost around 10–12 in production, test with the Bcrypt Hash Generator, and generate strong passwords to begin with using the Password Generator.