Bcrypt Hash Generator & Verifier
Hash a password with bcrypt, or verify a password against an existing hash — entirely in your browser
Generate a hash
Each +1 doubles the work. 10–12 is the common production default; higher values take noticeably longer to hash.
Verify a password against a hash
About this tool
The ToolNinja Bcrypt tool hashes passwords and verifies them against existing hashes using a pure-JavaScript bcrypt implementation, entirely in your browser. Bcrypt is the standard choice for storing passwords server-side specifically because it's deliberately slow — the cost factor (rounds) controls exactly how slow, making brute-force attacks against stolen password hashes impractical even as hardware gets faster. Unlike a plain SHA-256 hash, bcrypt automatically generates and embeds a random salt in every hash it produces, so hashing the same password twice always yields a different result, and there's no separate salt column to manage. Use Generate to produce a hash for testing an auth flow or seeding a database with known test credentials. Use Verify to check whether a given password actually matches a hash you already have — useful for debugging a login bug or confirming a migrated hash still validates correctly.
When to use it
- →Generating a bcrypt hash to seed test or development database records
- →Verifying a password actually matches a stored hash while debugging an auth bug
- →Checking what cost factor an existing hash was generated with
- →Testing how hashing time scales with the cost factor before picking a production value
Tips
- ◆A cost factor of 10–12 is the common production default — each +1 roughly doubles the time to compute, which is the entire point.
- ◆The three-character prefix ($2a$, $2b$, or $2y$) identifies which bcrypt variant produced the hash; all three are compatible for verification purposes here.
- ◆Bcrypt silently truncates input at 72 bytes — extremely long passwords beyond that length won't change the resulting hash.
Frequently asked questions
Why does hashing the same password twice give a different result?
Bcrypt generates a fresh random salt every time it hashes, and embeds that salt directly in the output string. That's by design — it's what makes precomputed rainbow-table attacks against bcrypt hashes infeasible, since every hash of the same password is still unique.
What cost factor should I actually use in production?
10–12 is the widely used range in 2026 — high enough to meaningfully slow brute-force attempts, low enough that legitimate logins don't feel slow. If your hardware is fast and login volume is low, 12–14 is reasonable; go lower only if login latency is a measured problem.
Is this the same bcrypt my backend uses?
The hash format and verification logic are fully compatible with bcrypt implementations in other languages (Node's bcrypt/bcryptjs, Python's bcrypt, Go's golang.org/x/crypto/bcrypt, Ruby's bcrypt gem) — a hash generated here will verify correctly against those, and vice versa.