Bcrypt
Hash text with bcrypt at your chosen cost factor, or verify a plaintext value against an existing bcrypt hash.
Hash
Verify
Recommended Settings
Pro Tips
- •Bcrypt automatically generates and embeds a random salt in every hash, so hashing the same text twice produces two different-looking (but equally valid) hashes
- •A higher cost factor makes hashing deliberately slower, which is the point - it makes brute-force password cracking attempts proportionally slower too
- •A cost factor of 10-12 is a common, reasonable default for most applications today - much higher values can noticeably slow down your login flow
- •Never hash the same password with a low-cost general-purpose hash like MD5 or SHA-256 for storage - use bcrypt or a similarly designed password hashing function instead
Most Popular
Most applications use a cost factor of 10-12, balancing security against login response time
When to Use This Tool
Generate a properly salted, slow hash suitable for storing user passwords.
Check whether a submitted password matches a stored bcrypt hash.
Generate test hashes while developing or debugging a login system.
Generate reference bcrypt hashes while migrating a system to proper password hashing.
How It Works
Generate a random salt and combine it with your chosen cost factor
Run the text through the bcrypt algorithm (based on the Blowfish cipher) for 2^cost iterations
Encode the salt, cost factor, and resulting hash together into bcrypt's standard $2a$ format string
100% Private
Files never leave your device. All processing happens locally in your browser.
Lightning Fast
Powered by bcryptjs (pure JavaScript bcrypt implementation) for optimal performance on modern browsers.
Open Source
Built with verified, open-source libraries. Fully transparent.
Frequently Asked Questions
Why does hashing the same text twice give different results?
Bcrypt automatically generates a new random salt each time, which is embedded directly in the output hash - this is intentional and is what protects against precomputed rainbow table attacks. Both hashes are equally valid for verifying that same text.
What cost factor should I use?
A cost factor of 10-12 is a common default that balances strong security with reasonable login performance - higher values are more secure but slower to compute.
Is my data sent to a server?
No. All hashing and verification happens entirely in your browser using a pure JavaScript bcrypt implementation.
Can I use this to hash real user passwords for my application?
The algorithm itself is production-grade, but always perform actual password hashing in your backend server code, not in a public browser tool, so the plaintext password is never exposed to a third party.
Why use bcrypt instead of SHA-256 for passwords?
General-purpose hashes like SHA-256 are designed to be fast, which makes them easier to brute-force. Bcrypt is deliberately slow and includes a built-in salt, making it purpose-built for secure password storage.