{{ result.hash }}
- Use cost factor 12 or higher for production
- Test performance on your hardware before deployment
- Higher cost = better security but slower performance
- Each increment doubles the computation time
- Store the full hash including salt and cost
ℹ️ About Bcrypt Generator
Bcrypt is an adaptive password hashing function from the OpenBSD project, designed by Niels Provos and David Mazieres for storing password verifiers instead of plaintext passwords. It is based on the expensive key setup phase of Blowfish and was introduced in the original OpenBSD bcrypt paper as a way to keep password checking deliberately costly as hardware gets faster.
Use bcrypt when you need a one-way password hash for account login, admin credentials, imported legacy user tables, framework compatibility, or security testing of an existing bcrypt policy. It is for password storage and verification, not encryption, API token generation, file checksums, or digital signatures.
A bcrypt hash stores the algorithm version, cost, salt, and derived hash in one modular crypt string. A typical value looks like $2y$12$7M8xdNcKkXvNHWKqHaZ9..g.Ez/8BZeC4vq4mkwpIagbqyCy/UrxS: 2y is the variant, 12 is the cost, the next 22 encoded characters are the salt, and the remaining characters are the password hash. The OpenBSD bcrypt manual describes the Blowfish crypt format, 128-bit salt, encoded rounds, and 72-byte password input limit.
Cost and salt details:
- Salt: each generated hash should use a new random salt; the salt is stored inside the hash string and does not need a separate database column.
- Cost: the work factor is logarithmic, so cost 12 is roughly twice the work of cost 11 and four times cost 10. Higher cost slows both legitimate logins and offline guessing.
- Versions:
$2a$,$2b$, and PHP's$2y$identify bcrypt-compatible variants; preserve the full stored string for verification. - Verification: never compare a freshly generated hash string directly, because the salt changes each time. Use bcrypt verification so the stored salt and cost are applied to the candidate password.
Examples: generating a hash for correct horse battery staple at cost 12 might produce the sample string above, while generating again should produce a different string because the salt changes. To verify a login, submit the candidate password and the stored bcrypt string; a matching password validates, and any different password fails without revealing the original secret.
Strength guidance: bcrypt remains a strong, widely supported password-hashing choice when configured with a modern cost and unique salts. The OWASP Password Storage Cheat Sheet recommends a bcrypt work factor of 10 or more for legacy bcrypt systems, tuning the value as high as your verification servers can tolerate. For new systems, prefer Argon2id when available, or scrypt when Argon2id is unavailable, because those algorithms add memory-hard resistance that bcrypt does not provide.
Limitations and privacy: bcrypt only protects stored password verifiers after a database leak; it does not fix weak user passwords, missing rate limits, credential stuffing, or compromised application servers. Many bcrypt implementations only process the first 72 bytes of a password, which can be shorter than 72 characters for UTF-8 input. This page calls the server-side API to generate and verify hashes, so avoid pasting live production passwords into any online tool unless you control the environment and understand the data path.
API Usage Example:
POST /api/tools/crypto/bcrypt
Content-Type: application/json
{
"password": "mySecretPassword123",
"cost": 12
}