Is my password sent to a server?

No. Hashing and verification run entirely in your browser using the bcryptjs library. Your password never leaves your device.

What cost factor should I use?

10 is the widely accepted default for web applications. It balances security and speed on modern hardware (roughly 100 ms per hash). Go higher (12–14) if your server can afford the extra latency; avoid anything below 10 in production.

What is the difference between bcrypt, Argon2, and scrypt?

All three are password-hashing algorithms designed to be slow by design. Argon2 (winner of the Password Hashing Competition) and scrypt offer stronger memory-hardness guarantees. bcrypt remains widely deployed and well-supported. For new projects, Argon2id is generally recommended where available.

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

bcrypt embeds a random 16-byte salt inside every hash. The salt is included in the stored hash string, which is why bcrypt.compare() can still verify the password later.

Bcrypt Hash Generator

Hash passwords with bcrypt or verify a password against a hash. Everything runs in your browser — passwords are never sent to a server.

Password

Cost factor

Controls how many rounds bcrypt runs

10Recommended ✓

Hashing time per login~12 ms

fasterslower + more secure

Industry standard — good balance of speed and security. Each +1 step doubles the time (2¹⁰ rounds total).

Bcrypt Hash

Hash output will appear here

Why bcrypt uses a salt

A salt is 16 random bytes generated fresh every time you hash a password. It's embedded directly in the hash string — that's the 22-character block after the cost factor.

❌ No salt

password123 → abc123

Same input = same hash. Rainbow tables crack millions at once.

✓ With salt (bcrypt)

password123 + XkR… → q7z…

password123 + mP2… → 8Yw…

Different hash every time. Tables are useless.

bcrypt handles salting automatically — you never need to manage salts manually. The cost factor makes every attempt slow, so brute-forcing is impractical even without a salt.

How to use it

1Select the Generate Hash tab, enter a password, and choose a cost factor (10 is the standard for production).
2Click Generate Hash — the bcrypt hash appears below, ready to copy.
3To verify a password, switch to the Verify tab, enter the plain-text password and the stored hash, then click Verify Password.

Common use cases

Hash a password before storing it in a database during development.
Verify that a plain-text password matches a hash stored in production to diagnose login issues.
Test different cost factors to balance security and performance for your server's hardware.
Generate test bcrypt hashes for unit tests or seeding a development database.

Frequently asked questions

Is my password sent to a server?: No. Hashing and verification run entirely in your browser using the bcryptjs library. Your password never leaves your device.
What cost factor should I use?: 10 is the widely accepted default for web applications. It balances security and speed on modern hardware (roughly 100 ms per hash). Go higher (12–14) if your server can afford the extra latency; avoid anything below 10 in production.
What is the difference between bcrypt, Argon2, and scrypt?: All three are password-hashing algorithms designed to be slow by design. Argon2 (winner of the Password Hashing Competition) and scrypt offer stronger memory-hardness guarantees. bcrypt remains widely deployed and well-supported. For new projects, Argon2id is generally recommended where available.
Why does the same password produce a different hash each time?: bcrypt embeds a random 16-byte salt inside every hash. The salt is included in the stored hash string, which is why bcrypt.compare() can still verify the password later.