Bcrypt Generator
Generate and verify bcrypt hashes in your browser with configurable cost.
Password Hash Speed Test
Type any password, then watch SHA-256, PBKDF2, and bcrypt run against it side-by-side. The point isn't the hashes themselves — it's the timing. SHA-256 finishes in microseconds. PBKDF2 with 100,000 iterations takes roughly 100 milliseconds. Bcrypt at cost 12 takes 250+ milliseconds. The slow ones are slow on purpose — that's what makes them suitable for passwords. Everything runs in your browser; nothing is sent or stored.
Password input
SHA-256
PBKDF2
Bcrypt
How to Use This Tool
- Type or paste a password — any string works. The same input goes through all three algorithms.
- Click Run Comparison — SHA-256 finishes nearly instantly, PBKDF2 takes about 100ms, bcrypt takes about 250ms at cost 12.
- Read the timings — each row shows the algorithm, the resulting hash, and how long it took. The ratio between fastest and slowest is the security story.
- Adjust the parameters — bump PBKDF2 iterations or bcrypt cost to see how parameters scale time linearly (PBKDF2) or exponentially (bcrypt).
Why Password Hashes Are Designed to Be Slow
When an attacker steals a database of password hashes, the only way to recover the original passwords is to guess each one and re-hash it until they find a match. The faster the hash function, the more guesses per second the attacker can try. Modern GPUs can compute over 10 billion SHA-256 hashes per second — meaning every common password gets tested against every account in minutes. The defender's only practical move is to make the hash computation slow, so the attacker can only try a few thousand guesses per second instead of billions.
Adaptive hash functions like bcrypt, scrypt, and Argon2 expose a work factor — a number that controls how slow the algorithm is. Each hash takes the same time on the defender's server (where you only do it once per login) and on the attacker's GPU (where they need to do it billions of times). Slowing down each computation by a factor of a million has no real impact on login latency but makes brute-force attacks impractical. Bcrypt was the first widely-deployed function with this property; PBKDF2 took the same approach using iteration count.
The numbers you see here matter because they're the same numbers the attacker sees. If your application hashes passwords with one round of SHA-256, an attacker with a stolen database recovers most passwords in minutes. If you use bcrypt at cost 12 or PBKDF2 with 600,000 iterations, the same recovery effort takes years per password. The choice of algorithm is far less important than the choice to use any modern adaptive hash at all.
Frequently Asked Questions
Why is SHA-256 too fast for password hashing?
SHA-256 was designed for integrity-checking and digital signatures, where being fast is a feature. A modern GPU can compute over 10 billion SHA-256 hashes per second, which means an attacker who steals your password database can try every common password against every account in minutes. Adaptive hashes like bcrypt and Argon2 are intentionally hundreds of thousands of times slower per hash, dropping that attack rate from 10 billion/sec to a few thousand/sec — at which point trying every common password becomes infeasible.
What are the algorithms tested here?
SHA-256 — a fast cryptographic hash, ideal for file integrity and signatures, terrible for passwords. PBKDF2 with 100,000 iterations and SHA-256 as the underlying primitive — slow on purpose, the algorithm built into the Web Crypto API. Bcrypt at cost factor 12 — the modern default work factor, run via the bcryptjs library. Argon2id is the latest recommendation but isn't available in browsers without a much larger WebAssembly bundle, so it's not in this tool.
Why do my timings differ from the example numbers?
The numbers in the lead are rough estimates from a typical desktop CPU. Your actual timings depend on your device's CPU speed, browser, and current load. The relative ordering — SHA-256 fastest, PBKDF2 slower, bcrypt slowest — stays the same on every device. What matters is the ratio: bcrypt should be at least 1000x slower than SHA-256, ideally more. If it isn't, your cost factor is too low.
Is PBKDF2 a good choice if my framework does not include bcrypt?
Yes — PBKDF2 with 600,000 iterations of SHA-256 (the OWASP 2023 recommendation) is a perfectly acceptable password hash. It's standardized, FIPS-approved, and built into every major language and platform including the browser's Web Crypto API. Bcrypt and Argon2 have stronger resistance to GPU and ASIC attacks, but PBKDF2 is fine for most threat models. The wrong choice is using a single round of SHA-256 or MD5; PBKDF2 with high iterations is not the wrong choice.
Does this tool send my password anywhere?
No. Hashing happens entirely in your browser — SHA-256 and PBKDF2 use the built-in Web Crypto API, and bcrypt runs via the locally vendored bcryptjs library. There are no analytics scripts capturing form input on this page. The page works fully offline once loaded. As with any browser-based crypto tool, treat it as a development utility — don't paste production credentials into a tool you don't fully trust, and prefer your application's own implementation for real hashing.