What is the difference between the $2a$, $2b$, and $2y$ prefixes?

The prefix in a bcrypt hash records the algorithm variant — which bug fix of bcrypt was used to generate it. They all use the same underlying algorithm, so any of them can be verified by any modern bcrypt library: $2a$ — the original, widely deployed prefix. Historically it had a bug handling the 8th bit of the password bytes on some implementations. $2b$ — the recommended modern default . It fixed the 8th-bit (high-bit / non-ASCII) handling bug found in older $2a$ implementations. $2y$ — the PHP-flavoured fix of the same 8th-bit bug, essentially equivalent to $2b$ . This tool always generates the recommended $2b$ prefix via bcryptjs. The $2a$ and $2y$ prefixes appear in hashes created by older or PHP-based systems; the explanation above helps you recognize them when migrating or when your application must accept hashes from multiple sources.

Does bcrypt have a 72-byte password limit?

Yes. bcrypt only uses the first 72 bytes of the password. Anything beyond 72 bytes is silently ignored — two passwords that share the same first 72 bytes produce the same hash. This can be a subtle security issue, so if users may have very long passwords, hash the password once with SHA-256 (or another pre-hash) before passing it to bcrypt.

How do I verify a bcrypt hash?

Switch to the Verify tab. Paste the bcrypt hash (e.g., $2b$12$... ) and enter the candidate password. The tool uses the cost factor and salt embedded in the hash itself — there is no need to know them in advance — and reports whether the password matches. $2a$ , $2b$ , and $2y$ hashes are all accepted.

Is the bcrypt tool free and private?

Yes. Bcrypt hashing runs entirely in your browser using the bcryptjs library — your passwords never leave your device. The 16-byte salt is generated locally by the bcryptjs library and embedded in the output hash. The complete hash string (cost factor + salt + digest) is produced entirely client-side. No input data is sent to any server. For stronger memory-hard protection, see our Argon2 tool .

Bcrypt Hash Generator — Salted Password Hashing

Securely hash passwords with an adjustable cost factor — bcrypt's built-in salt and deliberate slowness defeat rainbow tables and brute-force attacks.

Result will appear here

Password

Cost factor

Effective cost factor: 12. Higher is slower and stronger. Typical: 10-12.

What is Bcrypt Hash?

Securely store passwords with a hash that's deliberately slow to compute and includes automatic salting — this is called "bcrypt". Resistant to brute-force attacks.

Bcrypt is a password-hashing function based on the Blowfish cipher, designed specifically for securely storing passwords — the default choice for web applications because it's deliberately slow and salts every hash automatically. Unlike fast hash functions like SHA-256, bcrypt is intentionally slow; that slowness, powered by the Blowfish key schedule, makes brute-force cracking thousands of times costlier than with MD5 or SHA-256, and each hash gets a unique 16-byte salt to defeat rainbow tables. Use this tool to hash a password with an adjustable cost factor. Everything runs in your browser via the bcryptjs library, so passwords never leave your device.

Adaptive cost factor — the work factor can be increased over time as hardware gets faster, keeping hashes secure for years.

Built-in salt — bcrypt generates a unique random salt automatically, preventing rainbow table attacks.

Maximum input of 72 bytes — bcrypt truncates passwords longer than 72 bytes; use a pre-hashing step (SHA-256) for longer passwords.

Industry standard — used by most web frameworks (Django, Rails, Laravel) and recommended by OWASP for password storage.

Zero-Server Tool Data Guarantee

All hashing happens locally in your browser. Your password is never sent to any server.

How to Use

Hash or Verify

Use Hash to generate a bcrypt hash for a password, or Verify to test a candidate password against an existing $2a$/$2b$/$2y$ hash.

Input Your Password

Enter the password you want to hash or verify. The tool uses the bcrypt algorithm for high security.

Adjust Cost Factor

Select the number of rounds (cost factor, 8–14). Higher rounds increase security but take longer to compute.

Copy the Hash

Once generated, the hash is displayed. Use the copy button to save it for your database or application.

Common Use Cases

Password Storage

The primary use case — hash user passwords before storing them in your database. Even if your DB is leaked, passwords remain protected.

API Key Hashing

Store API keys as bcrypt hashes. Your application can verify a presented key against the hash without ever storing the plaintext.

Passphrase Verification

Verify master passwords or encryption passphrases against a stored bcrypt hash during unlock flows.

Legacy Migration

If you're migrating from MD5 or SHA-based password storage, re-hash all passwords with bcrypt on next login.

Implementation Examples

JavaScriptNode.js (bcryptjs)

const bcrypt = require('bcryptjs');

// Hash a password
const hash = await bcrypt.hash('mySecurePassword', 12);
// "$2a$12$LJ3m4ys3Lk0TSw..."

// Verify a password
const isMatch = await bcrypt.compare('mySecurePassword', hash);
console.log(isMatch); // true

Bcrypt vs Scrypt vs PBKDF2

Feature	Bcrypt	Scrypt	PBKDF2
Algorithm basis	Blowfish	Memory-hard	Hash iteration
Memory hardness	Low (4KB)	Configurable (high)	None
GPU/ASIC resistance	Moderate	High	Low
Max input size	72 bytes	Unlimited	Unlimited
Built-in salt?	Yes (auto)	No (provide your own)	No (provide your own)
Speed on modern CPU	~100ms (rounds=12)	Configurable	Configurable

Production Best Practices & Security

Use a cost factor of 10–12 — this balances security with acceptable login times (100–300ms). Why:Modern CPUs can compute hashes very quickly. Increasing the cost factor ensures that a single brute-force attempt takes enough time to make massive-scale attacks economically unfeasible.

Never store plaintext passwords — always hash with bcrypt before saving to your database. Why:If your database is ever compromised, plaintext passwords give attackers immediate access to all accounts. Hashing ensures that even with the data, the actual passwords remain unknown.

Use a unique salt per password — bcrypt does this automatically; never reuse salts across users. Why:Salts ensure that two users with the same password have different hashes. This prevents "Rainbow Table" attacks where attackers pre-calculate hashes for billions of common passwords.

Pre-hash long passwords — since bcrypt truncates at 72 bytes, SHA-256 the password first if users might have very long passwords. Why:Bcrypt's underlying Blowfish algorithm has a hard limit of 72 characters. Anything beyond that is ignored, which could lead to security issues if not handled by pre-hashing.

Increase rounds over time — as hardware improves, bump the cost factor to maintain the same brute-force resistance. Why:Hardware (especially GPUs) becomes more powerful every year. A cost factor that was secure 5 years ago might be too fast today, allowing attackers to try more combinations per second.

Don't use bcrypt for general-purpose hashing — it's optimized for passwords; use SHA-256 or HMAC for data integrity. Why:Bcrypt is intentionally slow. Using it for file checksums or frequent data integrity checks will severely degrade your application's performance and provide no extra security for those use cases.

Frequently Asked Questions

Existing MD5 or SHA-256 hashes cannot be converted to Bcrypt — they use fundamentally different algorithms.

Instead, implement a lazy migration. When a user next logs in, verify their password against the old hash, then immediately re-hash it with Bcrypt and store the new hash. For users who haven't logged in recently, require a password reset.

Store a migration flag (e.g., version=2) alongside the Bcrypt hash to track which users have been migrated. This avoids forcing an immediate mass password reset.

Bcrypt's security comes from three properties: salting, adaptive cost, and inherent slowness.

Each hash gets a unique 16-byte salt generated locally by the bcryptjs library, which defeats rainbow table attacks and ensures identical passwords produce different hashes.

The cost factor is adjustable — as hardware improves, you simply increase the cost and Bcrypt stays ahead.

Because Bcrypt uses the Blowfish key schedule (a complex initialization process) as a core part of its algorithm, it resists both GPU and ASIC-based parallel cracking far better than fast hash functions.

For most applications in 2026, a cost factor of 12 (4,096 rounds) is the recommended baseline. It takes roughly 80-150ms on modern server hardware.

Cost 10 is acceptable for high-traffic login endpoints where latency matters (around 20-40ms). Cost 14 or higher is advisable for admin accounts, password manager master passwords, or other high-value credentials.

To find the right setting for your environment, benchmark with your production hardware. Target approximately 100ms verification time. The tool here lets you adjust the cost interactively so you can test different values.

The prefix in a bcrypt hash records the algorithm variant — which bug fix of bcrypt was used to generate it. They all use the same underlying algorithm, so any of them can be verified by any modern bcrypt library:

$2a$ — the original, widely deployed prefix. Historically it had a bug handling the 8th bit of the password bytes on some implementations.
$2b$ — the recommended modern default. It fixed the 8th-bit (high-bit / non-ASCII) handling bug found in older $2a$ implementations.
$2y$ — the PHP-flavoured fix of the same 8th-bit bug, essentially equivalent to $2b$ .

This tool always generates the recommended $2b$ prefix via bcryptjs. The $2a$ and $2y$ prefixes appear in hashes created by older or PHP-based systems; the explanation above helps you recognize them when migrating or when your application must accept hashes from multiple sources.

Yes — but carefully. Because bcrypt's work doubles with every cost increase, an overly high cost factor can become a denial-of-service vector: an attacker floods your login endpoint with many hash verifications, and each one burns ~250ms of CPU (or much more). If 1000 attackers each trigger a 1-second hash, your server is effectively offline.

Use the minimum cost that keeps legitimate logins fast (typically 10–12, ~100–300ms), and pair it with rate limiting, authentication, and per-IP quotas. Bcrypt's slowness protects stored hashes; it is not a substitute for server-side rate limiting.