What cost factor should I use?

Whatever makes one hash take about 250–500 ms on your production hardware — commonly 12 to 14 in 2026. Re-measure when you change instance types.

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

Each hash embeds a fresh random salt. That is the point: identical passwords across users produce unrelated hashes, defeating precomputed tables.

Is bcrypt still acceptable?

Yes, with an appropriate cost. Argon2id is the better choice for new systems because it is memory-hard, but bcrypt remains a legitimate, well-analysed option.

Does the $2a$/$2b$ prefix matter?

It identifies the variant. $2b$ is current; $2a$ appears in older hashes. Most libraries verify both, but generating with $2b$ is correct for new hashes.

Security🌐 YAS server-sideAPI availableadvanced

Bcrypt Hash & Compare

Generates and validates secure bcrypt password hashes with configurable work-factor cost rounds.

Processed by YAS · not stored

Ready to runInstant execution

All tools →

Result

—

What does this tool do?

Generates and validates secure bcrypt password hashes with configurable work-factor cost rounds.

Why would I use it?

You want to test whether a plaintext password matches an existing $2a$ or $2b$ bcrypt hash.
You are seeding an administrative database account with a secure hash.
You are evaluating the performance impact of bcrypt cost rounds (10 vs 12 vs 14).

Real-life example

Input

Password: SecretPassword123!, Rounds: 10

Output

$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

Uses cryptographically strong salt with adaptive work factor.

Input → Process → Output → Next

Input: Enter password and select mode (Hash generation or Verification).
Process: Executes standard bcrypt key derivation function with Blowfish cipher.
Output: Bcrypt hash string or boolean match verification result.
Next action: Store hash securely in your database User model.

Common mistakes

Using work factors < 10 in production (too fast, vulnerable to GPU cracking).
Exceeding 72 bytes password limit (bcrypt truncates passwords longer than 72 bytes).
Storing raw password in logs or unencrypted columns.

What the result means

An adaptive, one-way salted password hash or verification verdict.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/bcrypt-tester

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/bcrypt-tester" \
  -H "Content-Type: application/json" \
  -d '{"password":"SecretPassword123!","mode":"hash","rounds":10}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/bcrypt-tester", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "password": "SecretPassword123!",
  "mode": "hash",
  "rounds": 10
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/bcrypt-tester", json={"password":"SecretPassword123!","mode":"hash","rounds":10})
data = r.json()

Field	Type	Required	Description
password	string	Yes	Plaintext password
mode	string	No (default hash)	Mode: 'hash' or 'verify'
hash	string	No	Bcrypt hash to compare (when mode=verify)
rounds	integer	No (default 10)	Salt rounds (4–12)

Success response

{ "slug": "bcrypt-tester", "mode": "hash", "rounds": 10, "hash": "$2a$10$..." }

Hash password or verify plaintext against bcrypt hash.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How Bcrypt Hash & Compare works

Bcrypt is a password hashing function built on the Blowfish key schedule, deliberately made slow and memory-touching. The cost factor is a base-2 exponent: cost 12 runs 2^12 key-setup iterations, and each increment doubles the work. The output string packs the algorithm identifier, the cost, a 128-bit salt and the digest into a single 60-character value, which is why bcrypt needs no separate salt column.

The salt is generated per hash, so the same password produces a different hash every time — comparing two hashes for equality is meaningless. Verification re-derives the hash using the salt and cost parsed from the stored value and compares the result in constant time.

When to use it: real-world scenarios

Choosing a cost factor for your hardware

Measure until a single hash takes roughly 250–500 ms on your production instance. That is the balance between resisting offline attack and surviving a login stampede.

Verifying a migration between languages

A hash produced by Python's bcrypt must verify under Node's, and vice versa. Cross-checking catches encoding and prefix differences ($2a$ versus $2b$).

Confirming a legacy hash is still verifiable

Before migrating an old user table, confirm the stored format parses and verifies rather than discovering it during a login outage.

Demonstrating why salting matters

Hashing the same password twice and getting different results makes the rainbow-table argument self-evident.

Pro tips

Bcrypt silently truncates input at 72 bytes. Long passphrases beyond that contribute nothing — pre-hash with SHA-256 if you must support them, and be consistent about it.
Re-hash on successful login when the stored cost is below your current target. That upgrades the corpus gradually without a password reset.
Prefer Argon2id for new systems: it is memory-hard, which resists GPU and ASIC attacks better than bcrypt's CPU-bound design.
Never log or transmit a password on the way to hashing, and always compare using the library's verify function rather than string equality.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

72-byte input truncation is a property of the algorithm, not the implementation.
Bcrypt is CPU-hard but not memory-hard, so purpose-built hardware attacks it more efficiently than Argon2id.
Higher cost factors are slow by design; interactive use above cost 14 will feel unresponsive.
This runs server-side, so do not submit real user passwords or production hashes. The page is ad-free for the same reason.

Frequently asked questions

What cost factor should I use?: Whatever makes one hash take about 250–500 ms on your production hardware — commonly 12 to 14 in 2026. Re-measure when you change instance types.
Why does the same password produce a different hash each time?: Each hash embeds a fresh random salt. That is the point: identical passwords across users produce unrelated hashes, defeating precomputed tables.
Is bcrypt still acceptable?: Yes, with an appropriate cost. Argon2id is the better choice for new systems because it is memory-hard, but bcrypt remains a legitimate, well-analysed option.
Does the $2a$/$2b$ prefix matter?: It identifies the variant. $2b$ is current; $2a$ appears in older hashes. Most libraries verify both, but generating with $2b$ is correct for new hashes.