bcrypt hash generator with salt
Generate a bcrypt hash below and hash the same password twice to see the built-in salt at work — no manual salt field required.
A common misconception, cleared up
People frequently search for a "bcrypt hash generator with salt" expecting a form with two separate input fields — one for the password, one for a salt they provide themselves. bcrypt doesn't work that way, and understanding why is genuinely useful, not just a technicality.
Unlike MD5 or SHA-256, bcrypt has salting built directly into the algorithm. Every time you generate a bcrypt hash, the function automatically creates a fresh, cryptographically random 16-byte salt and folds it into the computation — and then encodes that same salt into the beginning of the output string, so it travels along with the hash rather than needing to be stored in a separate database column.
See it for yourself
Hash the exact same password twice using the generator on this page. You'll get two completely different-looking output strings, even though the input never changed. That's the embedded salt doing its job — it's the mechanism that stops an attacker from precomputing a single rainbow table that works against every account in a leaked database.
Anatomy of a salted bcrypt hash
$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW
2b— algorithm version identifier.12— the cost factor (212 rounds of internal computation).- Next 22 characters — the base64-encoded 128-bit salt, generated fresh for this hash.
- Final 31 characters — the resulting hash of password + salt + cost, run through bcrypt's Blowfish-based cipher.
When you later verify a password, the verification function extracts the salt and cost factor straight out of this string — that's why our bcrypt verifier tool only asks for the plaintext password and the full stored hash, never a separate salt value.
If you specifically need to supply your own salt
Some niche scenarios (reproducing a legacy system's exact hash output, cross-language test fixtures) call for a manually-specified salt rather than a randomly generated one. bcrypt implementations generally support this by accepting a pre-generated salt string instead of a cost factor. That's a lower-level operation than most password-storage code needs, and for everyday application development we'd recommend letting bcrypt generate its own salt, as this page's generator does by default.
Manual salting still matters — just not for bcrypt
If your project uses a general-purpose hash like MD5 or SHA-256 instead of bcrypt, manual salting is essential and none of it happens automatically. See our MD5 with salt and SHA-256 with salt tools for that workflow.
Frequently asked questions
Do I need to add my own salt when using bcrypt?
No. bcrypt generates a random salt automatically for every hash and stores it inside the resulting string, so you never manage a salt value yourself.
Why does the same password produce a different bcrypt hash every time?
Because a new random salt is generated on every call. This is intentional and is exactly what prevents identical passwords from producing identical, attacker-precomputable hashes.
Where is the salt stored if I don't store it separately?
It's encoded directly inside the bcrypt hash string itself, immediately after the version and cost factor. You only need to store the full hash string in your database — nothing else.