Bcrypt Hash Generator & Verifier
Hash a password with bcrypt at a chosen cost factor, or verify a password against an existing bcrypt hash. Runs locally via bcryptjs.
Private by architecture:
All processing is 100% client-side memory. Your data never leaves this browser tab.
Higher = slower to compute = more resistant to brute-force. Each +1 roughly doubles hashing time.
Sample Presets
Bcrypt Hash Structure Anatomy
$2a$ / $2b$ Algorithm Identifier
10 Cost Factor (2^10 = 1,024 rounds)
22 chars Random Salt (128-bit)
31 chars Ciphertext Checksum
About This Tool
Hashes a password with bcrypt at a configurable cost factor, or verifies a plaintext password against an existing bcrypt hash: both via bcryptjs running entirely in your browser. Bcrypt is a purpose-built password hash: it is deliberately slow and includes a per-hash random salt, making it suitable for storing credentials safely.
Bcrypt is specialized for passwords and truncates inputs beyond 72 bytes. For general checksums and file integrity, use Hash Generator (MD5/SHA family).
Key Features
- Hash mode: Generates a salted bcrypt hash from a password at your chosen cost factor.
- Verify mode: Checks a password against an existing bcrypt hash and reports match or mismatch.
- Adjustable cost factor: Slider from 4 to 15 rounds (default 10); each increment roughly doubles compute time.
- Hash shape validation: Verify mode checks that the hash matches valid bcrypt structure before comparing.
- Per-hash random salt: Handled automatically by bcryptjs; hashing the same password twice produces unique valid hashes.
- Fully client-side: No password or hash is ever sent over the network.
Frequently Asked Questions
Why does hashing the same password produce a different hash each time?
Bcrypt bakes a random salt into every hash it produces, encoded directly in the hash string (the 22 characters after the cost factor). This defeats precomputed rainbow-table attacks. Verify mode extracts the salt from the hash itself, so comparison still works correctly.
What cost factor should I use?
10 to 12 is a common standard in 2026. Higher numbers are more resistant to brute-force but slower for every authentication request. Each +1 roughly doubles hashing latency.
Is there a maximum password length?
Yes: bcrypt processes the first 72 bytes of input. Passwords sharing the first 72 bytes hash identically.
Why does Verify mode report "not a bcrypt hash" instead of comparing?
The hash field checks for the standard prefix ($2a$, $2b$, or $2y$), 2-digit cost, and 53-character salt+hash body before running comparison to prevent silent failures on invalid input.
Is this safe to use for real passwords?
Hashing uses standard bcryptjs in browser memory. For production authentication, always perform password hashing on your backend server.
