Salted by design
Every generated hash includes a fresh random salt.
Start typing to search 126 tools.
Use this free BCrypt Hash Generator to create a salted password hash with a configurable cost and copy it for secure password-storage testing.
BCrypt Hash Generator creates salted BCrypt password hashes using a configurable work factor. It is intended for developers, QA engineers, administrators, and students testing password-storage workflows.
Unlike a general checksum, BCrypt is deliberately slow and includes a random salt in the generated string. The same password therefore produces a different valid hash on each run. Verification does not regenerate an identical string; it checks the password against the stored hash.
Focused controls, predictable output, and a workflow designed around this exact transformation.
Every generated hash includes a fresh random salt.
Adjust the work factor from 4 to 15 for development and performance testing.
The algorithm version, cost, salt, and checksum are stored in one string.
Learn why verification differs from comparing two generated strings.
Practical details about input, output, privacy, limits, and the best way to use this tool.
BCrypt generates a new random salt each time. The salt is stored inside the hash string, so different results can all verify the same password.
Use password_verify in PHP or the equivalent BCrypt verification function in your language. Do not generate a second hash and compare the strings.
Choose the highest cost your production system can handle without unacceptable login delay. Benchmark on the actual infrastructure and review the value over time.
No. The standard encoded BCrypt string contains the version, cost, salt, and checksum.
BCrypt implementations commonly process only the first 72 bytes. Applications should document this behavior and consider modern alternatives such as Argon2id when appropriate.
No. Its random salt makes it unsuitable for deterministic file checksums. Use SHA-256 or another algorithm required by the checksum workflow.
No. Password verification tests a candidate password against the stored hash; it does not decrypt the original password.
No. Use non-sensitive test values unless you fully control and trust the environment.
BCrypt generates a new random salt each time. The salt is stored inside the hash string, so different results can all verify the same password.
Use password_verify in PHP or the equivalent BCrypt verification function in your language. Do not generate a second hash and compare the strings.
Choose the highest cost your production system can handle without unacceptable login delay. Benchmark on the actual infrastructure and review the value over time.
No. The standard encoded BCrypt string contains the version, cost, salt, and checksum.
BCrypt implementations commonly process only the first 72 bytes. Applications should document this behavior and consider modern alternatives such as Argon2id when appropriate.
No. Its random salt makes it unsuitable for deterministic file checksums. Use SHA-256 or another algorithm required by the checksum workflow.
No. Password verification tests a candidate password against the stored hash; it does not decrypt the original password.
No. Use non-sensitive test values unless you fully control and trust the environment.
BCrypt is a password-hashing function based on the Blowfish key schedule. It combines the password with a random salt and repeats an expensive setup operation according to the selected cost. The returned string contains everything needed for later verification except the original password.
A typical encoded result includes a version marker, a two-digit cost, and encoded salt and checksum data. Preserve the complete string exactly as returned. Truncating or reformatting it will prevent verification.
Random salting ensures that identical passwords do not produce identical stored strings. This reduces the usefulness of precomputed lookup tables and prevents an attacker from immediately seeing which accounts share the same password.
The cost is logarithmic. Increasing it by one approximately doubles the work required for hashing and verification. A value that is comfortable on a development laptop may behave differently on a busy production server, so benchmark realistic login traffic.
Do not select the maximum value automatically. Excessive cost can create availability problems, while a cost that is too low weakens resistance to offline guessing. Record the chosen value, measure latency, and review it as hardware changes.
Applications can inspect a stored hash and determine whether it should be replaced with a newer cost or algorithm after a successful login. In PHP, password_needs_rehash supports this migration pattern.
Never verify a password by generating a fresh BCrypt hash and comparing strings. A fresh random salt makes the strings different. Instead, pass the candidate password and stored hash to password_verify or an equivalent library function.
The verification function reads the version, cost, and salt from the stored string, repeats the calculation, and compares the result using the implementation’s safe comparison logic.
Database columns must be wide enough for the complete encoded string. Store it as text without trimming characters.
BCrypt already generates and stores a random salt. Do not replace the library mechanism with one shared application salt.
Two hashes for the same password normally differ. Use a verification function rather than direct equality.
Many BCrypt implementations consider only the first 72 bytes. Unicode passwords may reach that limit with fewer visible characters. Document the behavior or choose a modern password-hashing function with requirements that fit your application.
Use established password APIs, secure random sources, rate limiting, multi-factor authentication where appropriate, and transport encryption. Hashing is only one part of account security.
Argon2id is often preferred for new systems when supported, while BCrypt remains widely deployed and well understood. Follow current platform guidance and regulatory requirements.
Use this online generator only with non-sensitive test data. Production passwords should be hashed inside the trusted application environment and never logged or transmitted to unrelated tools.
Confirm that the database stores the complete string, verification uses a BCrypt-aware function, cost is benchmarked on production-like hardware, login endpoints are rate-limited, password resets invalidate old credentials, and rehashing is supported when parameters change.
This BCrypt Hash Generator creates a salted password hash for safe development tests. The BCrypt Hash Generator keeps the complete encoded result visible, including the algorithm marker, cost, salt, and checksum. Use the BCrypt Hash Generator with test passwords only, then verify the stored string with a BCrypt-aware library function.
For implementation details, review the PHP password_hash documentation. This external reference explains the standard password API used by PHP applications.
Use the Hash Generator for deterministic MD5, SHA-1, SHA-256, or SHA-512 checksums. Those fast hashes are not substitutes for BCrypt password storage.