BCrypt Hash
Generate and verify bcrypt password hashes
Input
Bcrypt Hash
About this tool
Almost every hashing algorithm is designed to be fast. BCrypt is deliberately slow, and that inversion is the entire point. When an attacker steals a password database, their attack is offline and unlimited - they can try billions of guesses per second against a fast hash like SHA-256. Making each hash take a measurable fraction of a second reduces that to thousands, which turns a few hours of cracking into years. The cost factor controls how slow: each increment doubles the work, so 12 is roughly four times slower than 10. BCrypt also salts automatically, which is why hashing the same password twice produces two different outputs - and why precomputed rainbow tables are useless against it. The verify function is what checks a login, because it extracts the salt from the stored hash and recomputes. Note this tool processes on the server, so use test passwords rather than real credentials.
How to use this tool
- Enter a password to hashUse a test value. This runs server-side, so real credentials should not be pasted here.
- Choose a cost factor12 is the current sensible default. Each increment doubles the computation time.
- Generate the hashThe salt is included in the output string, which is why no separate salt column is needed.
- Use verify to check a matchVerification extracts the salt from the hash and recomputes - you never compare hashes directly.
What a bcrypt hash contains
A bcrypt hash such as $2b$12$... packs everything needed to check a password into one string: the version ($2b$), the cost factor (12), a 22-character random salt and the 31-character hash. Because each hash has its own salt, hashing the same password twice gives different results - and both still verify.
Each step up in cost doubles the work. A cost of 10 to 12 is a common choice today; pick the highest value that keeps a login check under about a quarter of a second on your server.
Key features
- Deliberately slow, which is exactly what makes offline cracking impractical.
- Salting is automatic and stored inside the hash, removing a whole class of implementation mistakes.
- Adjustable cost factor, so the hash can be strengthened as hardware gets faster.
- Verify mode included, for testing that a password matches an existing hash.
- No account and no limit.
Common uses
- Understanding how BCrypt hashes are structured while implementing authentication.
- Generating a test hash for a development database seed.
- Verifying that your application produces the hash you expect.
- Comparing cost factors to choose one for production.
- Learning why password hashing differs from general-purpose hashing.
Tips for better results
- Use a cost factor of 12 or above for new systems. Recalibrate over time - what was slow enough in 2015 is not in 2026.
- Never store a separate salt. BCrypt embeds it in the hash string, and a hand-rolled salt column usually signals a misunderstanding.
- Always compare with the verify function, never with string equality on two hashes - the salts differ, so equality is always false.
- BCrypt truncates input beyond 72 bytes. That matters for very long passphrases, which is one reason Argon2 is often preferred now.
- For new systems, Argon2id is the current recommendation. BCrypt remains a perfectly reasonable choice and is far better than a fast hash.
Mistakes to avoid
- Using MD5 or SHA-256 for passwords. They are fast by design, which is precisely the wrong property here.
- Comparing two BCrypt hashes directly and concluding the password is wrong - different salts guarantee different hashes.
- Choosing a low cost factor to keep logins snappy, which hands attackers a much cheaper offline attack.
- Adding your own salt column, which suggests the embedded salt was not understood.
- Pasting production passwords into any online tool, including this one - it processes server-side.
Frequently asked questions
BCrypt is deliberately slow and includes a built-in salt, making it far more resistant to brute-force and rainbow-table attacks than fast general-purpose hashes like MD5/SHA-256, which were never designed for password storage.
No - BCrypt includes a random salt each time, so the same password produces a different hash output every time it's hashed. This is intentional and is what makes it resistant to precomputed rainbow-table attacks.
No - use test values. BCrypt hashing is computationally heavy by design and runs on the server here, so the password you type is transmitted. It is not stored, but real production credentials should never be pasted into any third-party tool regardless.
12 or above for new systems. Each increment doubles the work, so the right number is whatever keeps login times acceptable on your hardware while making offline cracking expensive - and it should be raised over the years as hardware improves.
Because BCrypt generates a random salt each time and embeds it in the output. That is deliberate - it defeats rainbow tables. Always check a password with the verify function, which reads the salt back out of the stored hash.
Argon2id is the current recommendation for new systems, mainly because it resists GPU and custom-hardware attacks better and has no input length limit. BCrypt remains a solid, widely-supported choice and is vastly better than any fast hash.
A hash like $2b$12$... starts with the version (2b), then the cost factor (12), then 22 characters of salt and 31 characters of hash. Because the salt and cost are stored inside it, the hash alone is enough to verify a password later.
Yes - BCrypt only uses the first 72 bytes of input, so longer passphrases are silently truncated. Some systems pre-hash long passwords with SHA-256 first; Argon2 has no such limit.
Check the cost stored in each hash when a user logs in; if it is below your new target, re-hash the password they just entered and save the new hash. Accounts upgrade gradually without forcing a reset.