Bcrypt Generator - Create Password Hashes Online
Bcrypt Generator
Hashing runs locally in your browser. Your password is never uploaded or stored.
What Is
A password hash is a one-way function that converts a password into a fixed-length string such that the original password cannot be recovered from it, but the same password can be checked against the hash later by hashing it again and comparing. bcrypt is the specific algorithm this tool implements, designed by Niels Provos and David Mazieres and released in 1999 as an OpenBSD password hashing scheme. It belongs to the family of adaptive or deliberately expensive key derivation functions and is built on the Blowfish block cipher.
Structurally, bcrypt generates a random 128-bit salt, mixes it with the password, then runs the expensive EksBlowfish key schedule an adjustable number of times where the count is the log base 2 of the work cost. Because that salt is embedded in the output, two bcrypt hashes of the identical password are different strings, which prevents an attacker from spotting accounts that share a password. The output uses the modular crypt format, beginning with a version prefix, then the cost, then a 22 character base64 encoding of the salt, then a 31 character encoding of the resulting hash, all separated by dollar signs.
Two consequences matter in practice. First, bcrypt silently ignores input beyond 72 bytes, so any password longer than that should be pre-hashed before bcrypt is applied, otherwise two long passwords sharing a prefix would be interchangeable. Second, the algorithm is one-way by design: verification requires the plaintext password, which is precisely why bcrypt must never be used for anything you need to read back, such as remembering a card number.
How to Use
- Open the Bcrypt Generator in your browser. Hashing is performed locally, so your password is never uploaded anywhere.
- Enter the password you want to hash in the input field. Consider a long passphrase, since length contributes far more resistance than symbol substitution.
- Choose a work factor from 4 to 15, or leave it at the recommended default if you are unsure. Higher costs take proportionally longer and are harder to attack.
- Check the timing shown next to the cost to confirm it matches your target, typically between 150 and 400 milliseconds on production hardware.
- Click Generate to produce the hash, then copy the resulting string including the version prefix, cost and salt into your password store.
- Use the verify section to confirm a password against an existing hash when you are testing an integration or migrating stored credentials.
- Store the complete hash string rather than only its tail, because bcrypt requires the version, cost and salt prefix to be present in order to verify it later.
Examples
Input: Password: correct-horse-battery-staple, cost 10
Process:
128-bit random salt, 2^10 EksBlowfish rounds, base64 encodeResult: 60-character hash beginning $2b$10$ — verification requires the same plaintext
Input: The same password hashed twice at the same cost
Process:
A fresh random salt is generated per invocationResult: Two completely different hash strings for identical input
Input: Cost comparison on typical server hardware
Process:
Cost 10 runs 2^10 rounds, cost 12 runs 2^12, cost 14 runs 2^14Result: Each step up roughly quadruples the work, so cost 14 is about 16x the time of cost 10
Related Searches
People also search for: bcrypt generator, bcrypt hash, password hash generator, bcrypt cost factor, bcrypt salt, hash password.
bcrypt generatorbcrypt hashpassword hash generatorbcrypt cost factorbcrypt salthash passwordverify bcrypt hashbcrypt vs sha256bcrypt roundsgenerate salted hashsecure password hashingpassword hashing toolbcrypt onlineargon2 alternativebcrypt work factornode bcryptpython bcryptone way hashbcrypt cost 12offline password hash
Frequently Asked Questions
What cost factor should I use for bcrypt?
For most production systems a work factor of 12 is a sound default, giving roughly 250 to 400 milliseconds per hash on typical server hardware, while cost 10 is now often too fast to resist a dedicated attacker with modern GPUs. The important property is that you should choose a figure that makes your own login flow feel unremarkable, because hashing happens during authentication and anything noticeably slow is a usability problem that pushes people toward reauthentication shortcuts. If your servers are unusually powerful, measure at cost 12 and step up to 13 or 14 until a single hash takes a few hundred milliseconds. Never pick a cost by copying another project's number, since the figure only means something relative to the hardware doing the work, and treat any stored cost as something to re-measure and increase as hardware improves.
Why are two hashes of the same password different?
Because bcrypt generates a fresh random 128-bit salt for every single hash. That salt is not a secret, it is simply recorded in the output so the verification step can reproduce the original computation, but its randomness ensures that identical passwords produce completely unrelated hash strings across different accounts. This defeats a large class of precomputation attacks, including rainbow tables, in which an attacker hashes every likely password once in advance and then looks up matches. It also prevents a subtler leak, where an attacker who obtains your user table could otherwise immediately see which accounts share a password by comparing hash strings. The practical implication is that you cannot detect a reused password by comparing stored bcrypt hashes, and you must perform the check by verifying candidate passwords, which is exactly why detecting password reuse requires deliberately trying a password against other accounts.
Is bcrypt or SHA-256 better for storing passwords?
Use bcrypt, and the reason is the cost factor rather than any clever mathematics. A single round of SHA-256 is designed to be extremely fast, and that is exactly what you do not want for password storage, because a GPU can compute billions of them per second and an attacker testing a leaked table of hashes gets enormous numbers of free guesses. bcrypt is intentionally slow and its per-hash cost is tunable, so you can dial it up over time as hardware improves without changing the stored format. Argon2id is now often preferred where available and is generally the stronger recommendation for new systems, with bcrypt remaining perfectly acceptable and far more widely supported. What you must never do is store passwords as plain SHA-256, or as an unsalted hash of any kind, regardless of which algorithm you pick.
Can a bcrypt hash be reversed back to the original password?
No, and that is the entire point of choosing a password hash over encryption. bcrypt is a one-way function, so there is no key, no setting and no paid tool that will turn a hash back into the password. The only practical way to recover a password from a bcrypt hash is to guess candidate passwords, hash each one with the same cost and salt, and compare, which is precisely the attack bcrypt is designed to make slow. This also explains a constraint that surprises people: you cannot use bcrypt for anything you need to read back later, such as stored card numbers, customer encryption keys or reversible password recovery, because the system would be unable to retrieve the original value. Those need real encryption with a managed key, not a one-way hash.
What happens if I forget the cost and salt when storing a hash?
Then the hash can never be verified, and the account is unrecoverable, because bcrypt needs all four parts of the string to reproduce the computation. A complete bcrypt hash is the version prefix, the cost, the salt and the resulting hash, joined by dollar signs, and it is always 60 characters long. Libraries such as bcryptjs and the Python bcrypt package return this whole string from a single generate call, so your database column should store the complete value rather than a trimmed portion. Storing only the final segment, or only the part after the salt, silently breaks login for every user, and no amount of debugging the password itself will help. A length check of 60 characters is a useful sanity test on any column that is supposed to hold bcrypt hashes.
Does bcrypt have a maximum password length?
bcrypt considers only the first 72 bytes of the password and ignores everything beyond that, a historical artefact of its Blowfish key schedule rather than a deliberate security limit. The practical consequence is that two passwords longer than 72 bytes which share a prefix will authenticate against each other, so a 100 character passphrase whose first 72 bytes match another would be treated as the same password. This is a real risk with long passphrases, which is exactly the kind of password you should be encouraging, and long values such as full sentences can comfortably exceed the limit. The standard mitigation is to pre-hash the password with SHA-256 and base64, then pass that fixed-length result into bcrypt. If your language library handles this automatically, prefer that implementation, and otherwise verify the behaviour before you rely on very long passphrases.