Storing passwords as plain text is a breach waiting to happen. So is hashing them with something fast, like MD5. Understanding how bcrypt works is the fastest way to close that gap.
Bcrypt was built for one job: protecting passwords, not scrambling data. It's slow on purpose, it salts automatically, and it's the default choice in most serious authentication libraries today.
Why regular hashing fails for passwords
Hash functions like MD5 and SHA-256 are built for speed — checksums, file integrity, fingerprinting data. A modern GPU computes billions of SHA-256 hashes per second. That's great for checksums, but terrible for password storage.
If an attacker steals your password database, a fast hash lets them try billions of guesses per second. Plain SHA-256 and MD5 also skip salting, so two users with the password "hunter2" get identical hashes — perfect for rainbow tables.
Generate secure hashes for files and data with our hash generator. Passwords need something different.
How bcrypt works
Bcrypt solves this with three design choices.
- Salt: embedded in every hash, so identical passwords produce different results.
- Cost factor: also called the work factor or salt rounds, this controls how many rounds bcrypt runs. Each +1 doubles the compute time.
- One-way design: bcrypt never decrypts anything — your server re-hashes the candidate password and compares it to the stored hash.
Bcrypt dates to 1999, based on the Blowfish cipher. This is the core of how bcrypt works: it stays deliberately slow as hardware improves, since you can raise the cost factor to compensate.
Reading a bcrypt hash
A bcrypt hash packs four pieces of information into one string.
$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW
$2b$— the algorithm version.12— the cost factor (4,096 rounds).R9h/cIPz0gi.URNNX3kh2O— a 22-character salt.PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW— the 31-character digest.
The salt travels inside the hash, so one string per user is enough to verify logins years later, even after raising the cost factor. Try the bcrypt generator to see how it reshapes the output.
bcrypt vs SHA-256
| SHA-256 | bcrypt | |
|---|---|---|
| Built for | Data integrity, checksums | Password storage |
| Speed | ~22 billion hashes/sec on an RTX 4090 | ~4 hashes/sec at cost 12 on the same GPU |
| Salt | Not built in — added manually | Automatic, embedded in the hash |
| Work factor | None, fixed speed | Tunable, adjusts with hardware |
The verdict: use fast hashes like SHA-256 for file integrity or checksums, pairing them with our HMAC generator for message authenticity. Reserve bcrypt for human-chosen secrets.
FAQ
Can a bcrypt hash be decrypted or reversed? No. Bcrypt is a one-way function — there's no decryption key. Your server re-hashes the entered password with the stored salt and compares the two. That's how bcrypt works, and it's why a stolen hash alone won't reveal the password.
How many salt rounds or what cost factor should I use? A cost factor of 12 is a solid default in 2026. It's a fraction of a second per hash on typical hardware, and each +1 doubles the work needed for a brute-force guess.
Is bcrypt better than SHA-256 for passwords? Yes, for passwords specifically. SHA-256 is built for raw speed, which makes stolen hashes easy to brute-force. Bcrypt's built-in salt and adjustable cost factor make each guess expensive — exactly what you want when protecting login credentials.
Wrap up
Bcrypt earns its place as the default choice for a simple reason: it does the opposite of a fast hash, slowing attackers down while staying fast enough for legitimate logins.
That's how bcrypt works in practice — slow by design, salted, and one-way. Pair it with strong passwords from our password generator, then try the free bcrypt generator to hash, tune the cost factor, and verify in seconds.
