What Bcrypt Is, In One Paragraph
Bcrypt is a password-hashing algorithm — a function that takes a plaintext password and returns a fixed-length string you store instead of the password itself. Two qualities make it useful for passwords specifically: it's deliberately slow (you tune how slow with the cost factor), and it embeds a random salt so two users with identical passwords get different hashes. Slow plus salted means brute-forcing leaked password hashes goes from "minutes" with MD5 or SHA-1 to "centuries" with bcrypt.
It was published in 1999, has been the default password hash in Django, Rails, Spring Security, Laravel, and most other major frameworks for over a decade, and is still recommended by OWASP today. The Bcrypt Generator hashes a plaintext (with a cost you choose) and verifies a plaintext against an existing hash.
How the Microapp Bcrypt Generator Works
Pick mode (Hash a password, or Verify a hash). Hash mode: type the plaintext, slide the cost factor (4-14), click Generate. Verify mode: paste an existing hash plus the plaintext to check, click Verify. The result is Match (✓) or No match (✗).
Both operations run entirely in your browser using the bcryptjs library. Your plaintext password and the secret hash never leave your machine — there's no server roundtrip, no logging, no analytics on what you paste. The Web Crypto API doesn't include bcrypt natively (it has SHA, HMAC, AES), so we use the JS implementation.
hello at cost 10. Output: $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy. Re-running the hash on the same input produces a different output every time (because of the random salt), but bcrypt.compare("hello", <any hash>) returns true for both. The salt is embedded in the hash itself — no separate column required.
What the Cost Factor Actually Does
Bcrypt's cost (the integer between the second and third $ in the hash) controls the number of internal rounds: 2cost. Cost 10 = 1,024 rounds. Cost 11 = 2,048. Cost 12 = 4,096. Each step doubles the work. The point is to tune the time-per-hash to roughly 100-300ms on your auth server — slow enough that brute-forcing leaked hashes is impractical, fast enough that legitimate logins still feel instant.
| Cost | Rounds | Approx. time on a modern server | Use case |
|---|---|---|---|
| 4 | 16 | ~1ms | Tests, fixtures only — never production |
| 10 | 1,024 | ~100ms | OWASP minimum for production |
| 12 | 4,096 | ~400ms | Banks, password managers, high-security apps |
| 14 | 16,384 | ~1.5 seconds | Diminishing returns; users feel the latency |
Modern recommendation: cost 10-12 in production. Above 12 you start adding noticeable login latency for users; below 10 you risk falling behind hardware advances. Re-tune every 2-3 years as machines get faster.
Why Bcrypt Salts Automatically
Every call to bcrypt.hash() generates a fresh 16-byte random salt and embeds it in the output hash. The format is $2a$10$<salt><hash> where the first 22 base64 characters after the cost are the salt and the rest is the hash. To verify, bcrypt extracts the salt from the stored hash and re-hashes the candidate password with it — if the result matches, the passwords are the same.
Why this matters: without a salt, two users with the same password produce the same hash. Attackers precompute "rainbow tables" mapping common passwords to their hashes; one lookup cracks every user with "password123" simultaneously. With per-user salts, each hash is unique even for identical passwords, which makes rainbow tables useless and forces attackers to brute-force each hash individually.
What's With $2a, $2b, $2y?
Three near-identical bcrypt versions, all interoperable for verification. $2a is the original 1999 implementation. $2b fixed a Unicode handling bug in 2014. $2y is a PHP-specific marker that means "the same as $2a but generated by PHP." All three verify against bcrypt.compare regardless of which version generated them. Modern code generates $2a or $2b; legacy PHP databases often have $2y.
Should I Use Argon2 Instead?
Argon2id won the Password Hashing Competition in 2015 and is OWASP's first-choice recommendation for new systems. It's memory-hard (slow on GPUs), better-tunable (you control time, memory, and parallelism independently), and wasn't designed in 1999. New systems should use it if their stack supports it.
Bcrypt remains acceptable everywhere and is what most existing systems use — there's no urgency to migrate working bcrypt deployments. The choice for new systems: Argon2id if your library supports it (Node has argon2, Python argon2-cffi, Rust argon2); bcrypt if you're stuck with older tooling or if your team is more familiar with it.
Common Pitfalls
Storing the salt separately. Don't. The salt is part of the hash output — store the whole 60-character string in one column. Splitting it into separate columns adds bugs and zero security.
Reusing the cost factor across decades. If your codebase still uses cost 8 from 2010, you're under-protected against modern hardware. Bump to 10-12 and re-hash users on next login.
Mixing bcrypt with another fast hash first. Don't pre-hash the password with SHA-256 before passing to bcrypt — bcrypt has a 72-character input limit and pre-hashing produces fixed-length output that can hide truncation issues. Pass passwords directly to bcrypt; it handles the input correctly.
Comparing hashes with === in JavaScript. Always use bcrypt.compare() for verification — it does the salt extraction and timing-safe comparison. Direct string comparison is wrong on multiple levels.
Related Tools
For one-way hashes meant for integrity checking (file checksums, content addressing), use the SHA-256 Generator or MD5 Hash Generator. To generate strong random passwords to feed into bcrypt, see the Password Generator. For random tokens (different from passwords — never need to be hashed before storage), the Token Maker is the right choice. For two-factor authentication codes, see the OTP Generator.