What is the bcrypt cost factor?

The cost factor, or work factor, sets the number of internal key-schedule rounds bcrypt runs as 2 to the power of the cost. A cost of 12 means 2^12 = 4096 rounds, so it controls how slow and therefore how brute-force-resistant the hash is.

Why does each +1 double the time?

Because the round count is 2^cost, raising the cost by one doubles the number of rounds and so roughly doubles the time. That exact doubling is why the tool can extrapolate every cost from a single measurement.

What cost factor should I use?

Pick the highest cost that keeps a single hash around 250 to 500 ms on your production server. That is slow enough to frustrate offline cracking yet fast enough to avoid login delays. Re-evaluate as hardware improves.

Why benchmark PBKDF2 instead of real bcrypt?

Browsers cannot run bcrypt without an external library, so the tool times a Web Crypto PBKDF2 derivation as a device-speed proxy and calibrates it against published bcrypt timings. The doubling relationship between cost factors is exact regardless.

Are the numbers exact?

Treat absolute times as calibrated guidance, not a guarantee. Real bcrypt timing depends on the implementation and CPU, so confirm with your server's own bcrypt benchmark before locking in a production cost.

bcrypt Cost Factor Estimator

bcrypt’s cost factor (also called the work factor or rounds) is the single knob that decides how slow password hashing is — and slowness is the whole point, because it throttles attackers running offline brute-force. This estimator benchmarks your device live and projects the hashing time for every cost factor so you can choose a defensible value.

How it works

The cost factor is logarithmic: bcrypt runs 2^cost iterations of its Eksblowfish key schedule. So:

Cost 10 → 1,024 rounds
Cost 12 → 4,096 rounds
Cost 14 → 16,384 rounds

Each +1 to the cost doubles the rounds and therefore roughly doubles the time. Given the time at any one cost, every other cost is time × 2^(target − measured) — an exact relationship.

Because browsers cannot run real bcrypt without an external library, the tool measures your device’s speed with a real Web Crypto PBKDF2-HMAC-SHA256 derivation (a fair proxy for heavy key derivation on your CPU), then calibrates that against published bcrypt timings to produce realistic absolute estimates.

Tips

Aim for roughly 250–500 ms per hash on your production hardware: slow enough to make offline cracking expensive, fast enough that logins feel instant and an attacker cannot trivially exhaust your CPU with spammed login attempts. Servers are usually faster than the browser, so re-run a true bcrypt benchmark on the server and bump the cost up over time as hardware gets faster.