Why does cost grow exponentially, not linearly?

Because it is **2^cost iterations of the inner Blowfish function**. Cost 10 = 2^10 = 1024 iterations, cost 11 = 2048, cost 12 = 4096. Every +1 doubles the time. For an attacker the same exponential growth: **cost 12 is 16x harder to crack than cost 8**.

Why not just use MD5 or SHA-256?

**Because they are too fast**. An NVIDIA RTX 4090 GPU computes ~100 billion MD5/s, ~10 billion SHA-256/s. It brute-forces "Summer2024!" in one second. bcrypt with cost 12 on the same GPU: ~10,000 tries/s, **a million times slower**. **Every modern app uses bcrypt, Argon2, or scrypt**, never plain SHA-256 for passwords.

bcrypt vs Argon2, which is better?

**Argon2id** is the modern winner of the [[Password Hashing Competition||industry competition 2013-2015 that picked bcrypt's successor]] (2015). It has **memory hardness** (defeats GPU/ASIC attacks). **For a new app, pick Argon2id** (OWASP recommendation). bcrypt **is still fine** for existing apps and ecosystems without Argon2 support. Never plain SHA.

Can I run the benchmark multiple times?

Yes, each run is a **fresh measurement**. Numbers can wiggle +/- 10% from CPU throttling, other apps, etc. **Median of 3 runs** filters most of the noise. For best accuracy: close other tabs, plug the laptop in, run it 2-3 times.

Why is cost 14 slower in Chrome than Firefox?

Different **JavaScript engines** (V8 vs SpiderMonkey) optimize bcrypt differently. The difference is **negligible**: both have the same exponential shape. In production you usually run bcrypt **server-side** (Node.js, Python, Ruby, ...), the browser benchmark is a **proxy for order of magnitude**.

Cost 31 is the maximum, why not just use it?

Because cost 31 = **2^31 = 2.1 billion iterations** = on a modern CPU **over 30 minutes for one hash**. User logins would take half an hour. Practical max is **cost 16-17** (a few seconds). Above that you flirt with Denial of Service via login.

Does the bcrypt hash change every time?

**Yes, the same password gives a different hash on every call**. Because bcrypt **automatically generates a random salt** and embeds it in the output. Format: `$2b$12$ `. Two users with the password "qwerty123" get **different hashes**, an attacker reading the database cannot tell they are the same.

Why does the benchmark stop at cost 14, not 31?

Because cost 15+ takes **15+ seconds in the browser** and would freeze the UI too long. **Cost 14 (~150 ms) is the practical upper bound** for typical web apps. Above that you usually switch to Argon2 with memory parameters.

What does "$2b$" at the start of the hash mean?

That is the **algorithm version** of bcrypt. **$2b$** is modern (since 2014, fixed a null-byte bug). $2a$ is older (1999, popular in PHP, had a special-char bug). $2y$ is a PHP-only variant. Every modern library (bcryptjs, bcrypt.js in Node) uses **$2b$**.

YourDevToolsPro

bcrypt Cost Analyzer

Measure which bcrypt cost factor fits your hardware. OWASP recommends 250-500 ms per hash.

LiveRuns in your browser

bcrypt cost factor analyzer

Find the best bcrypt cost factor for your hardware. The benchmark hashes a sample password across cost 4-14 and recommends the highest one inside the OWASP 250-500 ms window.

The benchmark hashes a sample password at cost 4, 6, 8, 10, 12, 14 (three rounds each, median). Takes ~5-15 seconds depending on your hardware.

Quick test: hash a real password

Type any password and pick a cost factor to see the exact time + the generated bcrypt hash on this device.

Cost10

Hashing happens locally. The test password never leaves your browser.

What is the bcrypt cost factor and why does it matter?

bcrypt has been the industry standard for over 20 years. Every login in your app is a password hash + compare with the database. The slower the hash, the harder it is for an attacker to guess passwords by trying millions of combinations. Enter the "cost factor": a parameter that exponentially scales compute time.

Cost 10 = ~10 ms per hash (fast hardware, fast user login). Cost 12 = ~40 ms. Cost 14 = ~160 ms. Cost 16 = >0.5 s (noticeably slow login). Trade-off: too low = easy brute force. Too high = bad UX and higher server cost.

OWASP recommends in 2025: aim for 250-500 ms per hash on your production hardware. Run the benchmark here on your machine, see the cost factor that lands in that window.

Everything runs locally. Your test password never leaves the browser.

How to use

Click Run benchmark. The tool hashes a sample password at cost factors 4, 6, 8, 10, 12, 14 (three times each).
A moment later you see the chart: Y axis is milliseconds, each bar is a different cost. Bars grow exponentially (each cost is 2x slower than the previous).
Recommendation: the highest cost that still fits inside the 250-500 ms window (green bar). Put that number in your app config.
Below: Quick-test lets you hash any password at any cost and see the exact time + the bcrypt hash for that password on this device.
Remember: the cost on your laptop is not the cost on your production server. Run the benchmark on the actual hardware where your app will run.

When to use it

Five common situations where a cost analyzer helps:

Picking a cost for a new app. You are hashing user passwords for the first time, you need a cost. The benchmark tells you: on this VPS, cost 12 is 280 ms, perfect.
Migrating to a stronger cost. Your app has used cost 10 for 3 years, time to bump it. The benchmark shows cost 13 is now only 200 ms on the new servers.
Diagnosing slow logins. Users complain about 2-second logins. Benchmark: ah, the team set cost 16, way too high for this box.
Hardware comparison. Old server vs new AWS instance, how much cost can you afford?
Team education. Show a junior how the cost factor works and why MD5 is not enough.

To generate other hashes (SHA-256, MD5, Argon2), use the password hash generator. To check if a password leaked, use pwned passwords.

Questions and answers

OWASP 2025: aim for 250-500 ms per hash. Cost 10 on a modern laptop is ~10 ms (too fast, vulnerable to brute force). Cost 12 is ~40 ms (better). Cost 13-14 is ~200-500 ms (ideal). On a weaker server cost 12 may already be in the target window. Benchmark on your own hardware.

Related tools

Password Hashes: MD5, SHA, bcrypt

16 hash algorithms: MD4, MD5, SHA, SHA-3, RIPEMD, MySQL, NTLM, HMAC, bcrypt - with optional salt.

Bcrypt Verify

Check whether a password matches a bcrypt hash. Match or mismatch in a second.

Password Generator

Create strong, cryptographically random passwords - entirely in your browser.

JWT Signer / Verifier

Sign a JWT with a secret or private key. Verify an existing token. HS/RS/ES/PS 256/384/512.

AES Encrypt / Decrypt

Encrypt text with a password (AES-GCM 256). Runs in your browser, nothing leaves the device.