Bcrypt Hash Generator & Checker
Hash passwords with bcrypt and verify hashes — all client-side, nothing leaves your browser
About Bcrypt
Bcrypt is the industry-standard password-hashing algorithm. Unlike fast hashing (MD5, SHA-256), bcrypt is deliberately slow: the cost factor (rounds) controls how many iterations are performed, making brute-force attacks computationally expensive. This tool generates bcrypt hashes and verifies passwords against existing hashes — all client-side in your browser, so your passwords never leave your device.
Examples
Hashing a password at cost factor 12
password: "MyS3cr3tP@ss"
rounds: 12
hash: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBPj/hq3H8G2mOA cost factor of 12 is the current production recommendation — it takes ~300 ms on modern hardware, which is fast enough for login flows but slow enough to deter offline cracking.
Verifying a password against a stored hash
password: "MyS3cr3tP@ss"
hash: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBPj/hq3H8G2mO
result: ✓ Matchbcrypt.compare() re-hashes the input with the salt embedded in the stored hash, then compares. A wrong password produces ✗ No match — no need to store the original password anywhere.
Examples
Hash a password at cost factor 10
password: P@ssw0rd!
rounds: 10$2b$10$NIS3VD8BGG0kXhEg3c.9XeFSTjjRgESC0W4m/6IgWgk.mg9OpMmliA 60-character hash with the `$2b$` algorithm tag, cost 10, a fresh 22-character salt, and a 31-character hash digest. Each call generates a new random salt, so two hashes of the same password are different — both are valid.
Hash a passphrase at cost factor 10
password: correct-horse-battery-staple
rounds: 10$2b$10$ZJiBNW7RxecNyC7cQBR5W.UsOIHacvSJG1h7ciE5gc0M05i4.cBSWLong passphrases are far more resistant to brute force than short complex ones — a 28-character passphrase at cost 10 takes orders of magnitude longer to crack than `P@ssw0rd!`.
Verify the password against the stored hash
password: P@ssw0rd!
hash: $2b$10$NIS3VD8BGG0kXhEg3c.9XeFSTjjRgESC0W4m/6IgWgk.mg9OpMmliPassword matchesThe Verify tab re-hashes the input with the salt embedded in the stored hash and compares; a wrong password returns 'No match' without ever exposing the stored hash's plaintext.
About this tool
Bcrypt is a deliberately slow password-hashing function: it repeats its key schedule 2^cost times, so every cost step roughly doubles an attacker's work per guess. This tool hashes a password at any cost factor from 4 to 15 and checks a candidate against an existing hash — entirely in your browser, so the password never leaves your device.
A hash such as $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy is one string: the $2b$ prefix marks the algorithm revision, 10 is the cost factor, and the remaining 53 characters hold a 22-character salt plus a 31-character checksum.
There is no decrypting a bcrypt hash: verification re-runs the hash with its embedded salt and compares — exactly what the Verify Password tab does. bcrypt also only considers the first 72 bytes of a password, so longer passphrases are cut there.
How to use this tool
Hash a password
On the Generate Hash tab, type the password and pick a cost factor; 10 is the default and 12 is a common production choice.
Wait for the result
Higher factors are slower by design; past cost 12 the interface flags the setting as slow.
Store the whole string
Copy the complete $2…$ hash — the salt is embedded, so nothing separate needs storing.
Check a login
On the Verify Password tab, enter the plain-text password and the stored hash to get a clear match or no-match verdict.
Use cases
Storing a user's password at signup
Hash the plaintext password at cost 10–12, store the 60-character hash in the database, and discard the original — the salt is embedded in the hash, so no extra column is needed.
Verifying a login attempt against a stored hash
Paste the user-typed password and the stored hash into the Verify tab to confirm they match before letting the user in.
Auditing password strength without sending data anywhere
Hash candidate passwords in the browser to time how long each cost factor takes on real hardware, and pick the highest factor your login latency can tolerate.
Re-hashing older accounts at next login
Verify against the legacy hash, and if the cost factor is below the current production target (10–12), re-hash with a higher factor and overwrite the stored value.
Anatomy of a bcrypt hash
| Segment | Meaning |
|---|---|
| $2a$ / $2b$ / $2y$ | Algorithm revision — the tool accepts all three when verifying |
| 10 | Cost factor; each +1 doubles the hashing time (tool range 4–15) |
| 22 characters | Base64-encoded random salt, generated fresh for every hash |
| 31 characters | Base64-encoded checksum your password must reproduce |
Common mistakes
Mistake:Treating bcrypt hashes as reversible.
Fix:Bcrypt is a one-way function — there is no decrypt step. To check a password you re-hash it with the stored hash's salt and compare; losing the hash means losing the password.
Mistake:Storing the salt separately from the hash.
Fix:The bcrypt output already embeds the salt in its first 29 characters. Splitting them apart is unnecessary and risks mismatched pairs that fail verification.
Mistake:Setting the cost factor to 4 for 'fast tests' and shipping it.
Fix:Cost 4 is only suitable for unit tests that exercise the code path; production logins should use 10–12. The tool exposes 4–15 explicitly so the lower bound is visible during debugging.
Mistake:Comparing the hashed password to a stored hash with a plain string equality.
Fix:Use `bcrypt.compare(input, storedHash)` (what the Verify tab runs) so timing-safe comparison is preserved and the cost factor from the stored hash is respected.
Frequently asked questions
Can a bcrypt hash be decrypted?
No. Bcrypt is one-way — the hash contains nothing to reverse, and the only attack is guessing, made expensive by the cost factor. To check whether a password matches a hash, use the Verify Password tab.
Which cost factor should I use?
The default 10 suits testing and low-traffic logins; 12 is widely recommended for production sign-ups. Go higher only if your login flow tolerates the delay — every step roughly doubles hashing time.
What is the difference between $2a$, $2b$ and $2y$?
They mark revisions of the bcrypt spec: $2a$ is the original, $2b$ fixed a wraparound bug with very long inputs, and $2y$ (common in PHP) behaves like $2b$. Verification treats them the same, and this tool accepts all three prefixes.
Why does the same password give a different hash each time?
Every hash embeds its own random salt, so identical passwords produce different strings by design. Verification still succeeds because the salt is read back out of the hash before re-hashing.
Related guides
Hash Generators Explained: MD5 vs SHA-256 vs BCrypt
What cryptographic hash functions do, which algorithms are still safe, and which to pick for checksums, fingerprints, or passwords — MD5, SHA-1, SHA-256, SHA-512, and BCrypt compared.
Encryption Tools Explained: AES vs BCrypt vs HMAC
Three cryptographic primitives developers constantly confuse — reversible encryption (AES), password hashing (BCrypt), and message signing (HMAC). What each one is for, and how to pick correctly.
References & standards
Related tools
Hash Generator
Generate multiple cryptographic hashes with comprehensive analysis, security information, file upload, and multiple output formats
Password Generator
Generate secure passwords with customizable options including length, character sets, and complexity requirements
Password Strength Checker
Analyze password security with real-time strength scoring and recommendations
Hash Comparison Tool
Compare hash values and generate hashes from text for verification