BCrypt hash
Generate bcrypt password hashes (cost 4–15), verify a password against a hash, and parse the version, cost, salt and digest — with the elapsed time for every operation.
Runs in your browserEvery computation happens in your browser — your data never leaves this device.
0 ms1024 iterationsWhat this tool does
- Generate a bcrypt hash to store in your database during sign-up or password reset, with the elapsed time shown so you can judge the server-side cost.
- Verify a password against an existing hash at login to confirm the user typed the original password.
- Audit hashes in a legacy system: parse the version, cost factor, salt and digest out of `$2b$10$…` and check whether the cost is still stuck at 4 or 5.
- Estimate the cost factor before load testing — each +1 doubles the work, and you can watch the timing change here.
Example
Input
Password “password123”, cost factor 10
Output
$2b$10$Ovw.3EE33b/WaRSbSzwlRuc74Y2HaQ.VXFXbyZIK/ItlEak9Mt/r2
bcrypt generates a fresh random salt every time, so hashing the same password twice gives different strings — that is expected, not a bug. The hash above is a real run and verifies against “password123”.
Frequently asked questions
Why is the hash different every time for the same password?
Because bcrypt creates a new random salt (22 characters) per call and stores it inside the hash string. That makes rainbow tables useless and hides which users share a password. You do not need to store the salt separately — the verify step reads it from the hash.
What cost factor should I use?
Start at 10 and aim for roughly 100 ms per hash on your target server (this page shows the measured time). Every +1 doubles the work: cost 10 is 1024 iterations, cost 12 is 4096. This tool caps the range at 4–15 because anything higher freezes the page noticeably.
What happens with very long passwords?
bcrypt only uses the first 72 bytes and silently ignores the rest; the tool warns you once you pass that limit. It counts bytes, not characters — a Chinese character is 3 bytes, so 24 of them hit the ceiling. To support longer passwords, the usual fix is to SHA-256 the input first and hand that to bcrypt.
How is this different from SHA-256 or MD5?
SHA-256 and MD5 are designed for speed, so an attacker can try billions of candidates per second — they are the wrong tool for passwords. bcrypt is deliberately slow and its cost factor is tunable, so you can raise it as hardware gets faster. bcrypt also salts automatically, whereas with SHA-256 you must handle salting and rainbow tables yourself.
Do my password and hash leave the browser?
No. Hashing and verification run locally through bcryptjs and the page makes no network requests. Be aware that the computation is synchronous: at a high cost factor the page will briefly stop responding.
Keywords：bcryptpasswordhashcostsalt密码哈希加盐校验bcrypt 哈希