Bcrypt Hash Generator
Generate secure bcrypt hashes from passwords and verify password-hash pairs. Runs entirely in your browser — your password is never sent to any server.
🔐 Purpose-Built for Passwords
Unlike SHA-256 or MD5, bcrypt is designed specifically for password storage. It's intentionally slow and includes a salt to prevent rainbow table attacks.
⚙️ Adjustable Cost
The cost factor controls how slow the hash is. Double the cost = double the computation time. This lets you keep up with faster hardware over time.
🔒 100% Client-Side
Uses the bcryptjs library. Your password is never sent anywhere. Ideal for testing and verifying hash formats.
Frequently Asked Questions
What is bcrypt and why is it used for passwords?
Bcrypt is a password hashing function created in 1999 by Niels Provos and David Mazières. Unlike general-purpose hash functions (SHA-256, MD5), bcrypt is deliberately slow — it's designed to make brute-force attacks computationally expensive. It also automatically generates and embeds a random salt, preventing rainbow table attacks.
Why not use SHA-256 or MD5 to hash passwords?
SHA-256 and MD5 are designed for speed — they can compute billions of hashes per second on modern GPUs. This makes them unsuitable for passwords. Bcrypt is designed to be slow (configurable via cost factor) and is purpose-built for password storage. Always use bcrypt, Argon2, or scrypt for passwords — never SHA or MD5.
What does a bcrypt hash look like?
A bcrypt hash looks like: $2b$10$N9qo8uLOickgx2ZMRZo..... The $2b$ is the version, $10$ is the cost factor, the next 22 characters are the salt, and the remaining characters are the hash. The full hash is always 60 characters.
Should I use this tool in production?
This tool is designed for testing and development. In production, always hash passwords server-side in your backend code. Never send plaintext passwords to a third-party website for hashing, even one that claims to be private. For production, use bcrypt libraries for your language: bcryptjs (Node), bcrypt (Python), password_hash() (PHP).
What do the $2a$, $2b$, and $2y$ prefixes mean?
These are version prefixes embedded in every bcrypt hash. $2a$ is the original specification, $2b$ corrects a bug in the handling of long passwords in $2a$, and $2y$ is a PHP-specific variant of the same fix. All three are interoperable in practice, and modern libraries default to $2b$.
Why is every bcrypt hash exactly 60 characters?
A bcrypt hash is fixed-length: the $2b$ version prefix, two digits for the cost factor, a 22-character Base64 salt, and a 31-character checksum. The output length never varies with the password, which is why bcrypt hashes fit neatly into a fixed-size database column.
My password is longer than 72 characters. What should I do?
Bcrypt silently ignores everything past 72 bytes, so those extra characters give you no extra security. You can truncate the password yourself, or use a different algorithm such as Argon2id if you need to support very long passphrases.
How to Generate a Bcrypt Hash
Bcrypt hashing and verification happen entirely in your browser using the bcryptjs library. Your password never touches a server, which makes this tool safe for testing passwords for sample accounts, development environments, and verifying that your own backend produces formatted hashes correctly.
- Enter the password you want to hash in the first field. Use the Show button to reveal what you typed and double-check it before hashing.
- Pick a cost factor. 10 is the general recommendation, 12 is for high-security accounts. Each step up doubles the computation time, so on a typical laptop you will feel the difference between 10 and 12 immediately.
- Click Generate Hash. A 60-character hash like
$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWyappears in the output box, and the tool breaks it down into version, cost, salt, and checksum for you. - Copy and store the hash. Save it in your database's password column. Because bcrypt embeds its own salt, you never need to store the salt separately.
- Verify it. Paste the hash into the verify field, re-enter the original password, and click Verify. A green match confirms the pair is correct — this is exactly what your app does at login.
Bcrypt in Practice: Tips and Common Mistakes
The most common misunderstanding about bcrypt is the 72-byte limit. Bcrypt reads only the first 72 bytes of a password — not characters. A single accented letter or emoji can occupy two to four bytes in UTF-8, so a 40-character password with a few emojis can hit the limit early. Beyond that boundary, additional characters are silently ignored, so two different long passwords could produce the same hash.
The cost factor is a tradeoff between security and speed. Each increment doubles the work, and hardware only gets faster, so what is "slow enough" today will be disappointingly fast in a few years. Many production systems start at cost 12 and re-evaluate yearly. The good news: because the cost is stored inside the hash itself, your verification code does not need to know your chosen cost — it reads it from the hash. That also means you can detect old, weak-cost hashes in your database and rehash those users automatically on their next login.
Three tips to keep in mind when you integrate bcrypt into your own applications:
- Never hash passwords with SHA or MD5. Those algorithms are fast by design — billions of guesses per second on GPUs. Bcrypt, Argon2, and scrypt are deliberately slow.
- Use the default cost for your language's library. If you are unsure, cost 12 is a safe, widely used baseline for interactive logins.
- Don't add your own salt. Bcrypt generates a cryptographic random salt automatically and stores it in the hash. Adding an extra salt of your own is unnecessary and easy to get wrong.