Bcrypt Hash Generator & Verifier
100% local cryptographic processing. Your sensitive inputs never leave your device.
Salt Rounds
Higher numbers are more secure but take significantly longer.
How does Bcrypt Hashing work?
Bcrypt is a password-hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher. It incorporates a salt to protect against rainbow table attacks and is an adaptive function—over time, the iteration count (salt rounds) can be increased to make it slower, ensuring it remains resistant to brute-force search attacks even as hardware speeds increase.
Why Salt Rounds Matter
The salt rounds parameter represents the cost factor. It determines how many iterations of the hashing algorithm are performed (calculated as 2rounds). For example, 10 rounds means 1,024 iterations, while 12 rounds means 4,096 iterations. While higher rounds significantly improve security against database leak decryptions, they require more computational time, so choosing a balance (usually 10-12 for user passwords) is standard.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Producing a hash to seed an admin account in a fresh database without ever storing the plaintext.
- Checking a stored hash against a candidate password while debugging a login that should work and does not.
- Reading the cost factor out of an existing hash to decide whether it needs rehashing.
- Generating a fixture for tests that exercise the verification path rather than the hashing path.
- Comparing the wall-clock cost of two cost factors before committing to one in production.
How it works in practice
A worked example
A long passphrase is being hashed for an admin account, and you want to know what bcrypt is actually storing before anything depends on it.
Password A correct horse battery staple correct horse battery staple correct hELEVEN-A-tail-that-differs-completely-AAAA Password B correct horse battery staple correct horse battery staple correct hELEVEN-B-a-totally-different-ending-BBBB Cost 10
Hash of A $2b$10$Dl9xEQ.7Y1B7KtXOuzl9p.5Ds0A3fCZBcjR/S5Fp2/YZ3sO1k66NK Verify B against it Match Verify "something else" No match
Those two are 109 and 107 bytes long and they share their first 72, which is everything bcrypt ever sees. The Blowfish key schedule takes a 72-byte key and the rest of the input is discarded before any hashing starts, so these are not similar passwords — they are one credential with two spellings, and either opens an account created with the other. That is the algorithm rather than this page, which is exactly why the generator shows you the prefix it is going to use rather than letting you assume.
The edge case that catches people
The ceiling is measured in bytes and nobody chooses a password by byte count. Seventy-two ASCII letters reach it, and so do eighteen emoji, because each one costs four bytes once encoded — and a phrase in Greek or Japanese gets there sooner still. So a character count tells you nothing about whether you are near the edge, and crossing it produces no error and no warning from any library: you simply get a hash of the first part. Anything accepting a passphrase should measure it with a byte encoder before storing it.
When not to use this tool
Only for secrets a person chose. A randomly generated API key already carries more entropy than any attacker can work through, so spending a hundred milliseconds per verification on it buys nothing, and the byte ceiling starts to matter once tokens get long — a plain digest of a high-entropy secret is the right tool, or a lookup on its identifier. For a system being designed now, Argon2id is the current recommendation instead: it can be tuned to need memory as well as time, which is what resists the GPU and ASIC attacks a small working set does not.
Frequently Asked Questions
- What is bcrypt and why is it used for passwords?
- bcrypt is a password-hashing function intentionally designed to be slow. Its cost factor lets you increase work as hardware improves — keeping brute-force attacks expensive. It also auto-generates a unique salt per hash.
- What cost factor should I use?
- Cost factor 10–12 is the standard for 2024. Factor 10 takes ~100 ms per hash on modern hardware — slow enough to deter attackers, fast enough for user login. Use 12+ for high-security systems where extra latency is acceptable.
- Can a bcrypt hash be reversed or decrypted?
- No. bcrypt is a one-way function — the hash cannot be decrypted. Verification works by hashing the candidate password with the same embedded salt and comparing the results.
- What is the salt in a bcrypt hash?
- A random 22-character value bcrypt generates and embeds in the output (the '$2b$10$...' prefix). The salt ensures two users with identical passwords produce different hashes, defeating rainbow table attacks.
- How do I verify a password against a stored bcrypt hash?
- Use bcrypt.compare(plaintext, storedHash) in Node.js or the equivalent in your language. Never compare strings directly — bcrypt must re-hash with the embedded salt. This tool generates the hash; use bcrypt verify at runtime.
Common errors and gotchas
- Raising the cost factor without measuring. Each increment doubles the work, and a value that is comfortable on a laptop can stall a login endpoint.
- Adding your own salt. Bcrypt generates one and stores it inside the hash, so a second salt is either redundant or actively harmful.
- Truncating silently. Most implementations ignore everything past 72 bytes, so a long passphrase can have its tail quietly discarded.
- Comparing hashes with string equality. Two hashes of the same password differ because the salts differ; you must use the verify function.
- Storing the cost factor separately from the hash, when it is already encoded in the prefix and will drift out of sync.