Each +1 roughly doubles the hashing time. 10-12 is a common default.
Hash to see the bcrypt output here.
Hash text with bcrypt at a chosen cost factor, and verify a plaintext against an existing bcrypt hash. Hashing runs in a background Web Worker so the page never freezes.
Hashing and comparison run locally in your browser via bcryptjs, off the main thread in a Web Worker. Nothing is uploaded, and neither the plaintext nor the resulting hash is ever included in a share link.
MD5 and SHA-256 are fast — exactly the wrong property for password storage, since it makes brute-forcing cheap. Bcrypt is deliberately slow and salted, which is what password hashing needs. Use the Hash Generator for file integrity, bcrypt for passwords.
Bcrypt generates a random salt for every hash, even for identical input — expected and correct. The salt is stored inside the output string itself, so verification still works.
12 is the current baseline — a good balance of security and login speed. Go to 13-14 only if your login latency budget allows it.
No — bcrypt is one-way. The only way to check a password is to hash the candidate and compare it to the stored hash, which is what Verify mode does.
It identifies the bcrypt variant. Some older systems only accept $2a$ — if verification fails against a legacy system, check the prefix matches what it expects.
No — hashing and verification both run in a Web Worker in your browser. That matters more for a password tool than almost anything else on this site — pasting real user passwords into a server-side "free bcrypt generator" is a habit worth breaking.