What This Tool Does
This tool generates secure bcrypt hashes for passwords using a configurable cost factor. It can also verify if a given plaintext string matches an existing bcrypt hash. Uses `bcryptjs` entirely client-side.
Inputs Explained
- Mode: Choose whether to Hash a new string or Verify an existing hash.
- Plaintext / Password: The string you want to hash or check.
- Cost Factor: (Hash Mode) Determines how computationally expensive the hashing is (default 10).
- Existing Hash: (Verify Mode) The `$2a$` or `$2b$` bcrypt hash to test against.
How It Works
Bcrypt relies on the Blowfish cipher and salt generation. Hash mode generates a random salt and hashes the plaintext `2^cost` times. Verify mode extracts the salt and cost from the provided hash, re-hashes the plaintext, and securely compares the results.
Formula / Logic Used
Bcrypt Hash Generator & Verifier
Securely hash passwords or verify bcrypt signatures locally.
Step-by-Step Example
Hash Generation:
Plaintext: password123
Cost: 10
Result: $2a$10$vI8aWB... (Salt and hash combined)
Verification:
The string password123 combined with the salt from the hash will yield the same result, confirming a match.
Use Cases
- Database Seeding: Generate secure mock passwords for test databases.
- Debugging Auth: Verify if a specific password matches the hash stored in your DB.
- Testing Costs: Experience how long different cost factors (10, 12, 14) take to compute in real-time.
- Security Education: Understand the structure of bcrypt (`$2a$10$salt+hash`).
Assumptions and Limitations
- Bcrypt truncates passwords at 72 bytes. Any characters beyond the 72nd byte are ignored during hashing.
- Cost factors above 14 will freeze the browser for several seconds or minutes depending on your CPU.
- Runs in a single browser thread. It is not suitable for bulk-hashing thousands of passwords.
- Uses the `$2a$` prefix via `bcryptjs`, which is standard and highly compatible.
Frequently Asked Questions
What does the $2a$, $2b$, $2y$ prefix mean in a bcrypt hash?
They're version identifiers for different bcrypt implementations. $2a$ was the original. $2x$ and $2y$ were PHP-specific patches around a sign-extension bug discovered in 2011. $2b$ is the current canonical version, fixing the same bug correctly across all platforms. For new applications, $2b$ is the safe choice; legacy systems may use $2a$ or $2y$ and that's fine — they all verify each other's hashes if the bug doesn't trigger. Most modern bcrypt libraries default to $2b$. The cost factor (the next number, like $2b$12$...) is far more important for security than the version letter.
Is it safe to use an online bcrypt generator for production passwords?
Honest answer: not for actual user passwords. An online tool means the password leaves your machine — even if our generator runs entirely in the browser (which ours does, with no server transmission), there's no way for you to verify that without inspecting the code. For production, hash passwords inside your application using your stack's bcrypt library: bcrypt in Node, passlib in Python, password_hash() in PHP, BCrypt in Java. Our generator is great for testing, demos, generating sample data, or one-off admin password hashes you immediately copy and use offline. Never paste real user passwords.
What is a bcrypt salt and where is it stored?
A salt is random bytes mixed into the password before hashing, so identical passwords produce different hashes — this defeats rainbow-table attacks. Bcrypt generates a fresh 16-byte salt for every hash. The clever bit: bcrypt embeds the salt directly inside the output string. A hash like $2b$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy decomposes as: $2b$ (version), $12$ (cost), 22 chars of base64 salt, then 31 chars of base64 hash. So you store one string in your database, and the verify function knows exactly how to extract everything. No separate salt column needed.
How long is a bcrypt hash?
Always exactly 60 characters. The structure is fixed: 4 chars for $2b$, 3 chars for the cost (e.g., 12$), 22 chars for the base64-encoded salt, and 31 chars for the base64-encoded hash. So when designing your database, use VARCHAR(60) or CHAR(60) for the password column. Some developers reserve VARCHAR(255) for safety, but it's wasteful since bcrypt outputs nothing longer. If you ever see a hash that's not 60 chars, something's wrong — truncated storage, double-encoding, or a non-bcrypt format mixed in. Bcrypt's 72-byte input limit also matters: longer passwords are silently truncated.