Bcrypt Password Hash Generator & Verifier

Generate bcrypt password hashes with adjustable cost factor (salt rounds 4–16) and verify plaintext passwords against existing bcrypt hashes. The industry-standard password hashing algorithm used by Node.js, Python, Ruby, and PHP frameworks. All hashing runs in your browser.

Bcrypt Generator: Enter a password and select a cost factor (10–12 recommended) to generate a bcrypt hash. To verify, paste a password and a bcrypt hash to check if they match. Used for secure password storage.

Bcrypt Hashing

Generate secure Blowfish-based hashes with custom work factors.

Text to Hash

Salt Rounds (Cost Factor): 10Standard

Faster / Less SecureSlower / More Secure

Higher rounds exponentially increase the time needed to crack the hash but also increases generation time. 10-12 is recommended for modern web apps.

Hash Verifier

Compare a plain-text string against an existing Bcrypt hash to verify accuracy.

Plain Text String

Bcrypt Hash

Waiting for input to verify...

Developer Note

Bcrypt verification is safe to perform client-side as the hash contains the salt needed for comparison. No data is sent to the server.

Key Takeaways

Bcrypt is a password hashing function designed to be slow — resistant to brute force
Cost factor (salt rounds) controls computational difficulty: 10 = ~100ms, 12 = ~400ms
Each hash includes a random salt — same password produces different hashes
Output format: $2b$[cost]$[22-char salt][31-char hash]
Industry standard for password storage in web applications

What is Bcrypt Generator?

Bcrypt Generator — A Bcrypt Hash Generator is a free tool that hashes passwords using the bcrypt algorithm and verifies plaintext passwords against existing bcrypt hashes.

Generate bcrypt password hashes and verify passwords against existing hashes with this free online tool. Bcrypt is the industry-standard password hashing algorithm used by Express.js, Django, Ruby on Rails, Laravel, and Spring Boot for secure credential storage. Set the cost factor (salt rounds) from 4 to 16 — higher values increase computation time exponentially, making brute-force attacks impractical. Each hash automatically includes a unique random salt, so the same password produces different hashes every time. Use the verifier to check if a plaintext password matches a stored bcrypt hash during development and QA testing.

How to Use Bcrypt Generator

1
Enter the password you want to hash in the input field.
2
Set the cost factor (10–12 recommended for production, 4–6 for fast testing).
3
Click Generate to create the bcrypt hash — copy it for your database seed or auth config.
4
Switch to Verify mode to check if a plaintext password matches an existing bcrypt hash.

Key Features

Bcrypt hash generation with adjustable cost factor (salt rounds 4–16)

Password verification — check plaintext against existing bcrypt hashes

Automatic random salt generation (built into every bcrypt hash)

Output in standard $2b$ format compatible with all bcrypt libraries

Client-side hashing — passwords never sent to any server

Use Cases

Generating password hashes for database seed files and user migrations

Verifying bcrypt hashes during login flow development and debugging

Testing cost factor performance to balance security and login speed

Comparing bcrypt output across Node.js, Python, and PHP implementations

About Bcrypt Generator

Why Bcrypt Is the Default Password Hash

Bcrypt (published 1999 by Niels Provos and David Mazières) was the first widely-deployed password hashing function designed around the principle of deliberate slowness. Unlike SHA-256 or MD5 — which are designed to be fast — bcrypt uses a configurable work factor (the "cost") that doubles computation time with each increment. This intentional slowness makes brute-force password cracking impractical even with modern GPUs. Every major framework defaults to bcrypt: Django (since 1.4), Express.js (via bcrypt / bcryptjs), Laravel (Hash::make), Ruby on Rails (has_secure_password), Spring Boot (BCryptPasswordEncoder), Symfony, ASP.NET Core. After 25+ years of cryptanalysis, no practical attack against bcrypt exists.

Bcrypt Hash Format Anatomy

The bcrypt hash format is a self-contained string with all parameters embedded:

$2b$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
↑   ↑   ↑                      ↑
ver cost salt (22 chars)        hash (31 chars)

$2a$ / $2b$ / $2y$: algorithm version. $2b$ is current standard (since 2014). $2a$ is older but still safe. $2y$ is a PHP-specific fix for a 2011 bug.
cost: work factor, 4–31. Each increment doubles the time. 12 = 2¹² = 4096 rounds.
salt: 22 chars of base64-encoded 128-bit random salt
hash: 31 chars of base64-encoded 184-bit hash output

Cost Factor Calibration

Cost	Rounds	Hash time (modern server CPU)	Recommended use
4	16	~1ms	Unit tests only
10	1,024	~50–100ms	Low-traffic apps, legacy default
12	4,096	~200–400ms	Production default
14	16,384	~1.5s	High-security, infrequent login
16	65,536	~6s	Master keys, root passwords

Calibration rule: pick the highest cost that keeps the 95th-percentile login time under your latency budget. For consumer apps, target ~300ms per hash (cost 12 on most server CPUs). For internal admin apps, you can afford 1–2 seconds (cost 13–14). Increase cost by 1 every 2–3 years as hardware improves (Moore's law slowdown notwithstanding).

Bcrypt's 72-Byte Password Limit

Bcrypt silently truncates passwords longer than 72 bytes (~72 ASCII characters or fewer if the password contains multi-byte UTF-8). This means a 100-character passphrase has the same security as its first 72 characters — and even worse, two passwords identical in the first 72 bytes will hash to the same value. Mitigation: pre-hash the password with SHA-256 before passing to bcrypt: bcrypt(sha256(password)) — this normalizes any password length to 64 bytes (within the limit) and is what Dropbox, Auth0, and several major platforms do. Caveat: only use SHA-256 pre-hashing (not base64) because base64-encoded SHA-256 is 88 bytes — back over the limit.

Bcrypt vs Argon2 vs scrypt vs PBKDF2

Algorithm	CPU-hard?	Memory-hard?	Verdict
bcrypt	Yes	Mildly (4 KB)	Battle-tested default; safe choice
argon2id	Yes	Yes (GB-scale)	2015 PHC winner; modern best choice
scrypt	Yes	Yes	Solid, less ubiquitous than bcrypt/argon2
PBKDF2	Yes	No	FIPS-required; weakest of the four

Recommendation: use argon2id for new projects if your stack supports it; use bcrypt if you need maximum compatibility or are already in a bcrypt ecosystem. Migrate from PBKDF2 if possible.

Production Login Flow

On signup: const hash = await bcrypt.hash(password, 12); db.users.insert({email, hash});. On login: const ok = await bcrypt.compare(password, db.users.find(email).hash);. Never store the plaintext password. Never compare hashes with == — bcrypt.compare uses constant-time internally to prevent timing attacks. Implement rate-limiting on login endpoints (e.g., 5 attempts per IP per 10 minutes) to make even high-cost bcrypt brute-forcing impossible online. Add 2FA / WebAuthn / passkeys for high-value accounts.

Frequently Asked Questions

What cost factor (salt rounds) should I use for bcrypt?: Use 10–12 for production web applications in 2026. Cost factor 10 takes ~100ms, 12 takes ~400ms. Each increment doubles the time. Use 4–6 for unit tests to keep test suites fast.
Why does the same password produce different bcrypt hashes?: Bcrypt automatically generates a unique random salt for each hash. The salt is embedded in the hash output, so verification still works — bcrypt extracts the salt during comparison.
Is bcrypt better than SHA-256 for passwords?: Yes. SHA-256 is too fast for password hashing — attackers can try billions of guesses per second. Bcrypt is intentionally slow and includes automatic salting, making it far more resistant to brute-force attacks.
What is the difference between bcrypt and Argon2?: Bcrypt is CPU-hard (slow to compute). Argon2 is both CPU-hard and memory-hard, making it more resistant to GPU and ASIC attacks. Bcrypt is more widely supported; Argon2 is newer and recommended for high-security applications.
Can I verify a bcrypt hash from another programming language?: Yes. Bcrypt hashes are portable across languages. A hash generated in Node.js can be verified in Python, PHP, Ruby, or any language with a bcrypt library, as long as the $2b$ format is used.
Should I store plaintext passwords in my database?: Never. Always hash passwords with bcrypt (or Argon2) before storage. Even if your database is breached, attackers cannot recover plaintext passwords from properly hashed values. Plaintext password storage is a top-10 OWASP vulnerability and a guaranteed compliance failure (PCI DSS, HIPAA, GDPR, SOC 2).
Does bcrypt have a 72-byte password length limit?: Yes — bcrypt silently truncates passwords longer than 72 bytes. A 100-character passphrase has the same security as its first 72 characters. To support longer passwords, pre-hash with raw SHA-256 before bcrypt: bcrypt(sha256(password)). Use the raw 32-byte digest, NOT base64 (which would be 88 bytes — back over the limit).
What's the difference between $2a$, $2b$, and $2y$ bcrypt versions?: $2a$ was the original version. $2y$ was a PHP-specific fix for a 2011 bug. $2b$ is the corrected modern version (since 2014) and is what every current library produces. All three versions verify correctly across libraries — you can verify a $2a$ hash with a $2b$ library. New hashes should always use $2b$.
How do I migrate from PBKDF2 / SHA-256 / MD5 to bcrypt without forcing password resets?: Use a lazy migration: on each successful login, after verifying the password against the old hash, re-hash with bcrypt and update the database. Mark each user record with which scheme its current hash uses. Over time (~6-12 months), most active users migrate naturally. After a cutoff date, force a password reset for any user still on the legacy scheme. This avoids angering users with a forced mass reset.
Is it safe to generate bcrypt hashes in a browser?: Yes for development, testing, generating database seed data, and learning. The salt uses window.crypto.getRandomValues() — cryptographically secure. For production password hashing of real user passwords, do it server-side so the password never leaves the secure server boundary (HTTPS-decrypted body → bcrypt → discard plaintext).

Loading your tools...

Cost

Rounds

Hash time (modern server CPU)

Recommended use

~1ms

Unit tests only

1,024

~50–100ms

Low-traffic apps, legacy default

4,096

~200–400ms

Production default

16,384

~1.5s

High-security, infrequent login

65,536

~6s

Master keys, root passwords

Algorithm

CPU-hard?

Memory-hard?

Verdict

bcrypt

Yes

Mildly (4 KB)

Battle-tested default; safe choice

argon2id

Yes

Yes (GB-scale)

2015 PHC winner; modern best choice

scrypt

Yes

Solid, less ubiquitous than bcrypt/argon2

PBKDF2

Yes

FIPS-required; weakest of the four

Frequently Asked Questions

What cost factor (salt rounds) should I use for bcrypt?

Use 10–12 for production web applications in 2026. Cost factor 10 takes ~100ms, 12 takes ~400ms. Each increment doubles the time. Use 4–6 for unit tests to keep test suites fast.

Why does the same password produce different bcrypt hashes?

Bcrypt automatically generates a unique random salt for each hash. The salt is embedded in the hash output, so verification still works — bcrypt extracts the salt during comparison.

Is bcrypt better than SHA-256 for passwords?

Yes. SHA-256 is too fast for password hashing — attackers can try billions of guesses per second. Bcrypt is intentionally slow and includes automatic salting, making it far more resistant to brute-force attacks.

What is the difference between bcrypt and Argon2?

Bcrypt is CPU-hard (slow to compute). Argon2 is both CPU-hard and memory-hard, making it more resistant to GPU and ASIC attacks. Bcrypt is more widely supported; Argon2 is newer and recommended for high-security applications.

Can I verify a bcrypt hash from another programming language?

Yes. Bcrypt hashes are portable across languages. A hash generated in Node.js can be verified in Python, PHP, Ruby, or any language with a bcrypt library, as long as the $2b$ format is used.

Should I store plaintext passwords in my database?

Never. Always hash passwords with bcrypt (or Argon2) before storage. Even if your database is breached, attackers cannot recover plaintext passwords from properly hashed values. Plaintext password storage is a top-10 OWASP vulnerability and a guaranteed compliance failure (PCI DSS, HIPAA, GDPR, SOC 2).

Does bcrypt have a 72-byte password length limit?

Yes — bcrypt silently truncates passwords longer than 72 bytes. A 100-character passphrase has the same security as its first 72 characters. To support longer passwords, pre-hash with raw SHA-256 before bcrypt: bcrypt(sha256(password)). Use the raw 32-byte digest, NOT base64 (which would be 88 bytes — back over the limit).

What's the difference between $2a$, $2b$, and $2y$ bcrypt versions?

$2a$ was the original version. $2y$ was a PHP-specific fix for a 2011 bug. $2b$ is the corrected modern version (since 2014) and is what every current library produces. All three versions verify correctly across libraries — you can verify a $2a$ hash with a $2b$ library. New hashes should always use $2b$.

How do I migrate from PBKDF2 / SHA-256 / MD5 to bcrypt without forcing password resets?

Use a lazy migration: on each successful login, after verifying the password against the old hash, re-hash with bcrypt and update the database. Mark each user record with which scheme its current hash uses. Over time (~6-12 months), most active users migrate naturally. After a cutoff date, force a password reset for any user still on the legacy scheme. This avoids angering users with a forced mass reset.

Is it safe to generate bcrypt hashes in a browser?

Yes for development, testing, generating database seed data, and learning. The salt uses window.crypto.getRandomValues() — cryptographically secure. For production password hashing of real user passwords, do it server-side so the password never leaves the secure server boundary (HTTPS-decrypted body → bcrypt → discard plaintext).

Tools

Finance

AI

Media

Marketing

More

Bcrypt Password Hash Generator & Verifier

Developer Note

Key Takeaways

What is Bcrypt Generator?

How to Use Bcrypt Generator

Key Features

Use Cases

About Bcrypt Generator

Why Bcrypt Is the Default Password Hash

Bcrypt Hash Format Anatomy

Cost Factor Calibration

Bcrypt's 72-Byte Password Limit

Bcrypt vs Argon2 vs scrypt vs PBKDF2

Production Login Flow

Frequently Asked Questions

Bcrypt Password Hash Generator & Verifier

Developer Note

Key Takeaways

What is Bcrypt Generator?

How to Use Bcrypt Generator

Key Features

Use Cases

About Bcrypt Generator

Why Bcrypt Is the Default Password Hash

Bcrypt Hash Format Anatomy

Cost Factor Calibration

Bcrypt's 72-Byte Password Limit

Bcrypt vs Argon2 vs scrypt vs PBKDF2

Production Login Flow

Frequently Asked Questions