Bcrypt Hash Generator & Checker
Generate bcrypt password hashes and verify passwords against existing hashes. Entirely client-side — nothing leaves your browser.
Why Use This Tool
🔒 Adaptive Hashing
Bcrypt uses a configurable cost factor that controls the number of hashing rounds. As hardware gets faster, you can increase the cost factor to keep brute-force attacks impractical without changing your codebase or stored hashes.
🥑 Built-in Salt
Every bcrypt hash includes a cryptographically random 128-bit salt generated using your browser's Web Crypto API. This means identical passwords produce different hashes every time, defeating precomputed attacks like rainbow tables.
🚫 No Server Required
This tool runs entirely in your browser using a pure JavaScript implementation of the bcrypt algorithm. Your passwords are never transmitted, logged, or stored on any external server. Close the tab and every trace is gone.
✅ Hash Verification
Already have a bcrypt hash? Switch to the Verify tab to check whether a plaintext password matches a given hash. The tool extracts the salt and cost factor from the hash automatically and performs a constant-time comparison.
Step-by-Step Guide
- Enter your password — Type or paste the password you want to hash into the password field. Bcrypt supports passwords up to 72 bytes in length; anything beyond that is silently truncated by the algorithm.
- Choose a cost factor — Select a cost factor between 4 and 14 from the dropdown. The default of 10 is suitable for most applications. Higher values make the hash slower to compute, which increases resistance to brute-force attacks but also increases server load during login.
- Generate the hash — Click "Generate Hash" and a random 128-bit salt will be created using
crypto.getRandomValues(). The bcrypt algorithm then processes your password through the Blowfish key schedule for 2n rounds. The resulting hash string includes the algorithm version, cost factor, salt, and digest in a single portable format. - Verify a password — Switch to the Verify tab, enter a plaintext password and a bcrypt hash, then click "Verify Password." The tool extracts the embedded salt and cost factor from the hash, rehashes the provided password with the same parameters, and tells you whether the two match.
The cost factor in bcrypt doubles the computation time with each increment. A cost of 10 takes roughly 100ms, while 12 takes roughly 400ms. For user authentication, cost 10-12 balances security with acceptable login latency. Benchmark on your production hardware and choose the highest cost that keeps response time under 500ms.
Comparing bcrypt hashes with a simple string equality check (== or ===). Because bcrypt includes a random salt, the same password produces a different hash every time. You must use the bcrypt verify function, which extracts the embedded salt, rehashes the candidate password, and performs a constant-time comparison. This tool's Verify tab handles this correctly.
If your passwords may exceed 72 bytes (common with Unicode or passphrase inputs), pre-hash them with SHA-256 before passing the digest to bcrypt. This preserves all entropy within bcrypt's 72-byte input limit. Many modern bcrypt libraries like bcryptjs offer this as a built-in option.
Practical Applications
Backend Developer Implementing User Registration
When building a signup flow, a backend developer hashes the user's chosen password with bcrypt at cost 12 before storing it in the database. During login, the server retrieves the stored hash, passes the submitted password to bcrypt's verify function, and grants access only if the hashes match. This approach means the server never stores or logs the plaintext password, and even a complete database breach reveals no usable credentials.
Security Auditor Testing Hash Strength
A security auditor extracts password hashes from a client's database (with authorization) and uses this tool to verify whether they are bcrypt hashes and what cost factor was used. By examining the hash format ($2b$10$ prefix indicates bcrypt version 2b at cost 10), the auditor can assess whether the cost factor is appropriate for current hardware and recommend an increase if the system was configured years ago when lower costs were standard.
Sysadmin Migrating from MD5 to Bcrypt
A systems administrator discovers that a legacy application stores passwords as unsalted MD5 hashes. They implement a migration strategy: on each user's next successful login, the application verifies against the old MD5 hash, then immediately rehashes the plaintext password with bcrypt and replaces the stored hash. This tool helps the admin generate sample bcrypt hashes at different cost factors to benchmark performance before deploying the migration.
Understanding Bcrypt: The Gold Standard for Password Hashing
Bcrypt is a password hashing function designed by Niels Provos and David Mazieres in 1999, based on the Blowfish block cipher. Unlike general-purpose hash functions such as MD5 or SHA-256, bcrypt was specifically engineered to be slow and computationally expensive, which is exactly what you want when protecting passwords. The core idea behind bcrypt is that verifying a legitimate user's password should take a fraction of a second at most, but an attacker trying billions of guesses should face an enormous wall of computation that makes brute-force cracking impractical.
The fundamental difference between hashing and encryption is that hashing is a one-way operation. When you encrypt data, you can reverse the process with a decryption key. When you hash a password with bcrypt, there is no mathematical shortcut to recover the original password from the hash output. The only way to determine whether a candidate password matches is to run it through the same hashing process and compare the results. This is precisely how login systems work: they store only the hash, never the plaintext password, and compare submitted passwords by hashing them fresh each time.
One of bcrypt's most important features is its built-in salt. A salt is a random value that is mixed into the hashing process before any computation begins. Because each hash gets its own unique salt, even two users with the exact same password will end up with completely different hash outputs. This eliminates an entire category of attacks: precomputed lookup tables and rainbow tables become useless because an attacker would need to build a separate table for every possible salt value, which is computationally infeasible for a 128-bit salt space.
The cost factor, sometimes called the work factor or log-rounds parameter, is what makes bcrypt an adaptive hashing algorithm. When you set a cost factor of 10, bcrypt performs 210 (1,024) iterations of the Blowfish key expansion. Increasing the cost by 1 doubles the computation time. This means that as processors get faster over the years, administrators can simply increase the cost factor to maintain the same level of brute-force resistance without requiring users to change their passwords or migrating to a different algorithm.
Why should you choose bcrypt over MD5 or SHA-256 for password storage? General-purpose hash functions are designed to be fast. A modern GPU can compute billions of SHA-256 hashes per second, which means an attacker can test billions of candidate passwords every second. Bcrypt, by contrast, is intentionally slow and memory-hard, making GPU-based parallel attacks far less effective. While newer algorithms like Argon2 offer even stronger defenses against specialized hardware attacks, bcrypt remains the most widely supported and battle-tested password hashing function available today, with native support in virtually every major programming language and framework.
FAQ
What cost factor should I use for bcrypt in a production application?
The optimal cost factor depends on your server hardware and acceptable login latency. Start by benchmarking: on your production server, measure how long a single bcrypt hash takes at cost 10, 11, 12, and 13. Choose the highest value that keeps the hash computation under 250-500 milliseconds. In 2026, cost 10 (roughly 100ms on modern hardware) is the minimum recommended default. Cost 12 (roughly 400ms) provides stronger protection for sensitive applications like banking and healthcare. Each increment doubles computation time, so moving from 10 to 12 quadruples the work. As hardware improves, periodically re-benchmark and increase the cost factor. You can rehash stored passwords at the new cost during each user's next successful login without requiring a password reset.
Why does bcrypt produce a different hash each time for the same password?
Bcrypt generates a fresh 128-bit random salt for every hash operation. This salt is combined with the password during the Blowfish key expansion, so even identical passwords produce completely different hash outputs. The salt is not secret — it is stored as part of the hash string (the 22 characters after the cost factor prefix). Its purpose is to prevent precomputed attacks: without a unique salt, an attacker could build one rainbow table and crack every password in a database simultaneously. With unique salts, each password must be attacked individually, multiplying the attacker's workload by the number of accounts in the database.
How do I migrate from MD5 or SHA-256 password hashes to bcrypt?
The safest migration strategy is gradual rehashing on login. When a user logs in, verify their password against the existing MD5/SHA-256 hash. If it matches, immediately rehash the plaintext password with bcrypt and replace the old hash in the database. Add a column to track which hashing algorithm each user's hash uses, and check it during authentication to route to the correct verification function. Users who never log in during the migration period will retain their old hashes, so set a deadline after which remaining accounts require a password reset. Never attempt to convert hashes directly — you cannot bcrypt an MD5 hash and get meaningful results, because bcrypt needs the original plaintext password.
How does bcrypt's internal Blowfish key schedule make it slow on purpose?
Bcrypt's expensive key setup (EksBlowfishSetup) repeatedly processes the password and salt through Blowfish's key expansion function. At cost factor n, this key expansion runs 2^n times. Each iteration modifies all 18 P-boxes and 1,024 S-box entries (4 KB of state), mixing in the password and salt alternately. This process is inherently sequential — each iteration depends on the output of the previous one — which prevents parallel speedup on GPUs or ASICs. After the key schedule completes, bcrypt encrypts the constant string "OrpheanBeholderScryDoubt" 64 times with the configured Blowfish state to produce the final 24-byte hash. The combination of iterative key expansion and the 4 KB working state makes bcrypt significantly more resistant to hardware-accelerated attacks than fast hash functions.
Should I switch from bcrypt to Argon2 for new projects?
If your platform has mature Argon2 library support, Argon2id (the hybrid variant) is the strongest choice for new projects. It provides configurable CPU time, memory usage, and parallelism, offering superior defense against both GPU-based attacks and side-channel attacks. Configure it with at least 64 MB of memory and a time cost yielding 0.5-1 second of hashing. However, if your stack lacks first-class Argon2 support, bcrypt at cost 12 or higher remains completely secure and battle-tested. The practical security difference between well-configured bcrypt and Argon2 is small compared to the risk of misconfiguring a less familiar algorithm. Both are vastly superior to any fast hash function like SHA-256 or MD5.
How do I handle bcrypt's 72-byte password limit with long passphrases?
Bcrypt silently truncates passwords at 72 bytes due to the Blowfish key schedule limit. For ASCII passwords, this means 72 characters — more than enough for virtually all real-world passwords. However, Unicode characters can use 2-4 bytes each, so a 30-character passphrase with accented or CJK characters could exceed the limit. The standard workaround is pre-hashing: compute SHA-256 of the password first, then pass the 32-byte digest to bcrypt. This preserves all entropy regardless of input length. Some libraries call this approach "bcrypt-sha256" and handle it automatically. When implementing this, ensure you Base64-encode the SHA-256 output to avoid null bytes that could truncate the bcrypt input prematurely.
Password Hashing Best Practices
Storing passwords securely requires a dedicated key derivation function that is deliberately slow and resource-intensive. The three leading algorithms today are bcrypt, scrypt, and Argon2. Each takes a different approach to making brute-force attacks impractical.
| Feature | bcrypt | scrypt | Argon2 |
|---|---|---|---|
| Year Introduced | 1999 | 2009 | 2015 |
| CPU Hardness | Yes (cost factor) | Yes (N parameter) | Yes (time cost) |
| Memory Hardness | Minimal (4 KB) | Yes (configurable) | Yes (configurable) |
| Parallelism Resistance | Limited | Good | Excellent (configurable) |
| Max Input Length | 72 bytes | Unlimited | Unlimited |
| GPU/ASIC Resistance | Moderate | High | Very High |
| Library Support | Excellent | Good | Growing |
Recommendation: For new projects, Argon2id (the hybrid variant of Argon2) is the strongest choice. It won the 2015 Password Hashing Competition and provides configurable CPU time, memory usage, and parallelism, offering the best defense against both GPU-based and side-channel attacks. Use at least 64 MB of memory and a time cost that results in roughly 0.5 to 1 second of hashing time on your server hardware.
For existing systems already using bcrypt, there is no urgent need to migrate. Bcrypt with a cost factor of 12 or higher remains secure against current attack hardware. Its 72-byte input limit is rarely a practical concern since passwords longer than 72 characters are extremely uncommon. The most important rule across all three algorithms is to never roll your own implementation. Always use a well-maintained, audited library and keep the cost parameters high enough that hashing takes meaningful time on your production hardware.