Password hash generator — bcrypt
This is the hash generator to use when the passwords you're hashing are going into a real, production user database.
Why this page exists separately from a generic hash generator
Search for "password hash generator" and you'll find plenty of tools that hand you an MD5 or SHA-256 digest and call it done. For an actual user authentication system, that's the wrong tool for the job — see our broader password hash generator page for the full explanation. This page is specifically the right one: bcrypt is the algorithm major frameworks and security guidance (including OWASP's Password Storage Cheat Sheet) recommend for hashing real passwords before they ever touch a database.
What makes bcrypt appropriate for real passwords
- Deliberately slow, and tunable. A configurable cost factor lets you keep hashing expensive enough to resist brute-forcing even as hardware improves over time — you just raise the cost factor.
- Salting is automatic. Every hash embeds its own random salt, so you never build or maintain a separate salt column, and identical passwords never produce identical stored hashes.
- Battle-tested. bcrypt has been in continuous use and cryptanalysis since 1999 with no practical breaks — a long track record matters a great deal in cryptographic tooling.
A typical signup-to-login flow
- User submits a new password at signup.
- Your backend calls a bcrypt hash function (e.g.
bcrypt.hash(password, 12)) and stores only the resulting string — never the plaintext password, not even temporarily in logs. - At login, the user submits their password again; your backend calls a bcrypt compare function (e.g.
bcrypt.compare(candidate, storedHash)) against the stored hash. - The compare function returns true or false — your application never needs to "read" or reconstruct the original password at any point.
Use this page's generator to produce sample hashes for testing that flow, and the combined generator and verifier tool to test the compare step as well.
Migrating an existing system off MD5 or SHA-256
If you inherited a system storing passwords as bare MD5 or SHA-256 hashes, the standard migration pattern is: on the user's next successful login (when you still have their plaintext password in memory, briefly, during the request), re-hash it with bcrypt and overwrite the stored value. Over time, as active users log in, the whole table converts to bcrypt without ever needing users to reset their passwords en masse.
Framework note
Most modern web frameworks (Django, Laravel, Rails, ASP.NET Identity) already default to bcrypt or Argon2 for password hashing out of the box — if you're using one of these, check whether you actually need a standalone hashing tool at all, or whether the framework's built-in mechanism already covers it correctly.
Frequently asked questions
Is bcrypt better than SHA-256 for passwords?
For password storage specifically, yes — bcrypt is deliberately slow and tunable, while SHA-256 is fast by design, which makes brute-forcing stolen SHA-256 password hashes dramatically cheaper.
Do I need to store the salt separately when using bcrypt for passwords?
No. The salt is embedded directly in the bcrypt hash string, so a single database column is all you need.
What cost factor should a production system use?
Most current guidance suggests 10–12, tuned against how much CPU time your servers can spend per login without hurting user experience — benchmark on your actual infrastructure.