Bcrypt Generator – Create and Verify Password Hashes
Create bcrypt hashes with a freely selectable cost factor and verify existing hashes. Entirely local in your browser – your input never leaves your device.
Generate bcrypt hash
Enter text or password
Choose cost factor
Hash structure
Verify bcrypt hash
Check whether a plaintext matches an existing bcrypt hash – e.g. to test your application.
Bcrypt generator: create and verify password hashes at the push of a button
With our free bcrypt generator you can create secure bcrypt hashes with a freely selectable cost factor in seconds – and conversely check whether a plaintext matches an existing hash. The entire computation is performed with the JavaScript library bcryptjs directly in your browser – entirely local, with no data transfer to a server.
Whether you, as a developer, need a test password for your database seeds, want to reset an admin account, maintain a .htpasswd file or simply understand how password hashing works: our bcrypt generator delivers standard-compliant hashes at the click of a button that are compatible with PHP, Node.js, Python, Java and all common bcrypt implementations.
What is bcrypt?
Bcrypt is a password hashing function developed in 1999 by Niels Provos and David Mazières for the OpenBSD operating system. It is based on the Blowfish encryption algorithm and was designed for a single purpose: to store passwords in such a way that they cannot be reconstructed without enormous effort, even in the event of a database leak.
The central idea of bcrypt is the adaptive cost factor: while hardware keeps getting faster over the years, the computational effort of bcrypt can simply be scaled along with it. A higher cost factor doubles the number of internal rounds with each step – and thus the time an attacker has to spend on every single guessing attempt. This keeps bcrypt a reliable standard even more than 25 years after its release.
Why bcrypt instead of MD5 or SHA-256?
General-purpose hash functions such as MD5 or SHA-256 were designed for speed – which is exactly what makes them unsuitable for passwords. A modern graphics card computes tens of billions of MD5 hashes per second and thereby runs through entire dictionaries in fractions of a second. Bcrypt, on the other hand, is deliberately slow and reduces an attacker's rate to a few thousand attempts per second – a difference of several orders of magnitude.
On top of that come two further decisive advantages:
- Integrated salt: Bcrypt automatically generates a random salt for every hash and stores it within the hash. Rainbow table attacks with precomputed hashes thus come to nothing – and identical passwords produce different hashes.
- GPU resistance: Bcrypt's memory-intensive internal structure is considerably harder to parallelise on graphics cards than simple hash functions such as MD5 or SHA.
- Future-proofing: If computing power increases, you simply raise the cost factor – without having to switch the algorithm.
Structure of a bcrypt hash
A bcrypt hash is always exactly 60 characters long and follows a fixed scheme, for example $2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW:
$2b$– algorithm version: Denotes the bcrypt revision.$2a$is the original variant,$2y$the PHP revision after a bugfix in 2011,$2b$the current OpenBSD revision. All are compatible in practice.12$– cost factor: The number of rounds as a power of two: 212 = 4,096 iterations.- Salt – the next 22 characters: The randomly generated salt in bcrypt base64 encoding.
- Hash – the last 31 characters: The actual hash value derived from password, salt and cost factor.
Because salt and cost factor are contained in the hash, an application needs no additional information to verify a password – the hash is fully self-describing.
The cost factor: security vs. performance
The cost factor (also called work factor or rounds) determines how compute-intensive the hashing is: at cost 12, bcrypt runs through 212 = 4,096 internal rounds, at cost 13 it is already 8,192. Each step therefore doubles the computation time – for you as well as for every attacker.
As a rule of thumb for production use: choose the highest cost factor at which a hash is still computed in roughly 100 to 500 milliseconds on your server hardware. For current hardware that means cost 12 as the recommended minimum; security-critical systems use 13 or 14. Values below 10 are considered insufficient today. With our bcrypt generator you can try out different cost factors directly and observe the computation time live in your browser.
Bcrypt in practice: code examples
The hashes created with our generator are fully compatible with all common bcrypt implementations. Here is how to use bcrypt in your own application:
PHP
// Create hash (bcrypt is the default algorithm)
$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);
// Verify password
if (password_verify($password, $hash)) {
// Login successful
}
// Check whether the hash needs an upgrade (e.g. higher cost factor)
if (password_needs_rehash($hash, PASSWORD_BCRYPT, ['cost' => 12])) {
$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);
}
Node.js (bcryptjs)
import bcrypt from 'bcryptjs';
// Create hash
const hash = await bcrypt.hash(password, 12);
// Verify password
const isCorrect = await bcrypt.compare(password, hash);
Python (bcrypt)
import bcrypt
# Create hash
hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))
# Verify password
is_correct = bcrypt.checkpw(password.encode(), hash)
Never store plaintext
Store passwords in the database exclusively as a hash. Even in the event of a data leak, your users' actual passwords stay protected this way.
Increase the cost factor regularly
Hardware gets faster – at login, use password_needs_rehash() to check whether the hash still matches the current cost factor, and rehash if necessary.
Mind the 72-byte limit
Bcrypt processes only the first 72 bytes. With very long passphrases or multi-byte characters (umlauts, emojis) you should keep the limit in mind.
Pepper as a supplement
A server-side, secret additional value (pepper) outside the database increases security further – for example via HMAC before bcrypt hashing.
Typical use cases for the bcrypt generator
- Development & testing: Generate test hashes for database seeds, fixtures and automated tests
- Admin accounts: Insert a password hash for a new user directly into the database via SQL
- Debugging: Check whether a stored hash really matches the expected password
- Migration: Validate hashes in advance when switching from MD5/SHA to bcrypt
- Learning & understanding: Follow the structure of bcrypt hashes and the effect of the cost factor live
Create bcrypt hashes in three steps
- Enter: Type in the password or text you want to hash – the byte counter warns you at the 72-byte limit.
- Choose cost: Set the cost factor – we recommend 12 or higher for production use.
- Generate & verify: Create the hash at the click of a button, copy it to the clipboard and verify it directly in the verification area if needed.
Frequently asked questions
Bcrypt is a password hashing function developed in 1999 by Niels Provos and David Mazières on the basis of the Blowfish encryption algorithm. It converts a password into a 60-character, irreversible string. What makes it special: bcrypt is deliberately compute-intensive and contains an automatically generated salt – which makes it ideal for securely storing passwords in databases.
No. Both creating and verifying bcrypt hashes happens entirely locally in your browser using the JavaScript library bcryptjs. Your input never leaves your device and is neither transmitted nor stored. You can check this yourself in the network tab of your browser developer tools.
For production use, a cost factor of 12 is the recommended minimum. Each step doubles the computational effort: cost 13 takes twice as long as cost 12. Choose the highest value that still gives an acceptable response time on your server hardware (rule of thumb: 100 to 500 milliseconds per hash). Values below 10 should no longer be used today.
No. Bcrypt is a one-way function (one-way hash) – there is no mathematical way to compute the original password back from the hash. The only option is trying candidates (brute force or dictionary attack), which is extremely slowed down by bcrypt's high computational cost. This is exactly why bcrypt is used for password storage.
Bcrypt generates a new, random salt for every hashing operation, which is factored into the hash and stored with the result. This means the same password always produces different hashes. That is intentional: salts prevent rainbow table attacks and obscure when multiple users use the same password. Verification still works because the salt is read out of the stored hash.
The prefix denotes the bcrypt version: $2a$ is the original revision, $2y$ was introduced by PHP after a bugfix in 2011 and $2b$ is the current revision from OpenBSD (since 2014). All three variants are compatible in practice – modern implementations such as PHP password_verify() or bcryptjs can verify hashes of all revisions. Our generator produces current $2b$ hashes.
By design, bcrypt processes only the first 72 bytes of the input – anything beyond that is silently ignored. With passwords this is rarely a problem, but it is relevant for long passphrases or API keys. Note: umlauts and special characters occupy several bytes in UTF-8. Our generator shows you the byte length of your input and warns you if the limit is exceeded.
Yes. More than 25 years after its release, bcrypt is still considered secure and continues to be recommended by OWASP for password storage, provided the cost factor is at least 10. Newer alternatives such as Argon2 (winner of the Password Hashing Competition 2015) or scrypt additionally offer protection through high memory requirements. For existing systems, however, bcrypt with an appropriate cost factor remains a solid choice.