What cost factor should I use for bcrypt?

10-12 is a common baseline for interactive logins today; higher costs like 14-15 are more resistant to offline cracking but add real latency, so benchmark on your actual server hardware before choosing.

Does this tool send my password to a server to hash it?

No, hashing and verification both run through the bcryptjs JavaScript library loaded into your browser tab, so the password and resulting hash never leave the page.

Why does the same password produce a different hash each time?

Bcrypt generates a fresh random salt on every hash call and encodes it into the output string, so hashing the identical password twice intentionally yields two different-looking hashes.

Can I read the cost factor back out of an existing hash?

Yes, the two digits after the algorithm identifier in a bcrypt string, like the 10 in $2b$10$, encode the cost factor, and this tool detects and displays it automatically in Verify mode.

Bcrypt Hash & Verify

Hash a password with bcrypt at a chosen cost, or verify one against a hash, locally.

Local, Runs entirely in your browser, your data never leaves your device.

Loading tool…

Hash and verify passwords with bcrypt

This tool hashes a password with bcrypt, or checks a password against an existing bcrypt hash, using the bcryptjs library running in your browser tab. You pick the cost factor, the slider goes from 4 to 15 rounds, which controls how expensive each hash is to compute. It's meant for debugging an auth flow or generating a test hash for a seed script, not for hashing your production users' real passwords server-side.

How to use the Bcrypt Hash & Verify

Switch between the Hash and Verify tabs depending on what you need.
Enter the password you want to hash or check.
Drag the cost factor slider between 4 and 15 rounds when hashing.
In Verify mode, paste an existing bcrypt hash to compare against.
Copy the resulting hash, or read the match/no-match result.

Bcrypt embeds its own random salt and the cost factor inside the hash string itself (the $2b$10$... prefix), so a plain hash comparison is enough to verify, there's no separate salt to manage or store.

Cost is exponential: cost 10 means 2^10 rounds, cost 15 means 2^15. Higher costs slow down both legitimate logins and offline brute-force attempts, so pick a value your server can afford under real login load.

Frequently asked questions

What cost factor should I use for bcrypt?: 10-12 is a common baseline for interactive logins today; higher costs like 14-15 are more resistant to offline cracking but add real latency, so benchmark on your actual server hardware before choosing.
Does this tool send my password to a server to hash it?: No, hashing and verification both run through the bcryptjs JavaScript library loaded into your browser tab, so the password and resulting hash never leave the page.
Why does the same password produce a different hash each time?: Bcrypt generates a fresh random salt on every hash call and encodes it into the output string, so hashing the identical password twice intentionally yields two different-looking hashes.
Can I read the cost factor back out of an existing hash?: Yes, the two digits after the algorithm identifier in a bcrypt string, like the 10 in $2b$10$, encode the cost factor, and this tool detects and displays it automatically in Verify mode.