Online Bcrypt Hash Tool: Cost Factors, Salt, and Password Verify

What Is Bcrypt

Bcrypt is a password hashing function based on the Blowfish cipher, designed by Niels Provos and David Mazières in 1999. It has been the industry workhorse for password storage for more than two decades: every major language ships a battle-tested implementation, and the on-disk format encodes algorithm version, cost, and salt in one string.

Unlike regular hashes (e.g., SHA-256), bcrypt is purpose-built for passwords — built-in salt and an adjustable cost factor. Open the Bcrypt Hash tool to generate or verify locally in the browser.

Why You Need Bcrypt

1. Resists brute force: Adjustable computation cost makes brute-forcing impractical
2. Built-in salt: Automatically generates a random salt per hash, preventing rainbow table attacks
3. Tunable cost factor: Increase computation cost as hardware improves
4. Time-cost tradeoff: Legitimate logins take milliseconds, but attackers trying billions of passwords would take centuries

Bcrypt Hash Format

The Bcrypt hash format is:

$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
│  │  │  └─────────────────────────────────── 22-char salt
│  │  └────────────────────────────────────── 31-char hash
│  └───────────────────────────────────────── Cost factor (cost=10)
└──────────────────────────────────────────── Algorithm version (2a)

Cost Factor

The cost factor determines Bcrypt's computation cost as a power of 2:

Tuning target: pick a cost that makes interactive login take ~100–300ms on production hardware. On 2026 laptops that usually lands at 12–13; cost 10 is often too cheap for new systems.

How to Use an Online Bcrypt Hash Tool

Using ToolVault's Bcrypt Hash Tool:

Generate Hash

1. Enter the plaintext password
2. Select a cost factor (default 10)
3. Click Hash
4. Copy the resulting Bcrypt hash

Verify Password

1. Enter the Bcrypt hash
2. Enter the password to verify
3. Click Verify
4. The tool indicates whether the password matches

Code Examples

Node.js

const bcrypt = require('bcrypt');

// Generate hash
const hash = await bcrypt.hash('myPassword123', 10);
// '$2a$10$N9qo8uLOickgx2ZMRZoMye...'

// Verify password
const isMatch = await bcrypt.compare('myPassword123', hash);
// true

Python

import bcrypt

# Generate hash
password = b'myPassword123'
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=10))

# Verify password
is_match = bcrypt.checkpw(password, hashed)
# True

Go

import "golang.org/x/crypto/bcrypt"

// Generate hash
hash, err := bcrypt.GenerateFromPassword([]byte("myPassword123"), 10)

// Verify password
err = bcrypt.CompareHashAndPassword(hash, []byte("myPassword123"))
// nil if match

Bcrypt vs other password hashes (and vs file hashes)

Do not confuse bcrypt with SHA-256 file checks. Hash verifier answers “did this download match the published digest?”. Bcrypt answers “does this password match the stored credential?”. Feeding a password into SHA-256 (no salt, no cost) is a storage anti-pattern; feeding an ISO into bcrypt is the wrong tool.

Storage habits that survive audits

1. Never store plaintext passwords — bcrypt or Argon2id only
2. Allow long passwords in the UI — bcrypt truncates at 72 bytes; document the limit and prefer passphrases that stay under it, or pre-hash with SHA-256 only when you fully understand the tradeoffs
3. Raise cost over time — compare-and-rewrite on next successful login (cost lives inside the hash string)
4. Re-hash on password change — new salt, current cost
5. Constant-time compare — use the library’s compare / timingSafeEqual, never === on hash strings

Password cluster on this site

The cost factor: tuning bcrypt's only meaningful dial

bcrypt's cost factor is log2 of the hash iterations: cost 10 = 1024 iterations, cost 12 = 4096, each +1 doubles time. The tuning method nobody should skip: measure on your production hardware — target 100-250ms per hash (user-invisible at login, expensive at scale for an attacker cracking leaked hashes). Cost 10 on a 2026 laptop is ~60ms (too cheap for new systems); cost 12-13 is the current sensible floor; cost 15 on a busy app server starves the thread pool. The migration subtlety: raising the cost silently invalidates nothing (verification reads cost from the hash itself — old hashes verify at old cost), so you can upgrade per-user at next successful login — compare-and-rewrite on login is the standard pattern, no flag day needed.

bcrypt vs Argon2 vs scrypt: the 2026 decision

bcrypt (1999): GPU-resistant via memory usage? No — bcrypt's memory footprint is tiny by modern standards; its resistance comes from age and ubiquity (every platform has a battle-tested implementation). Argon2id (2015, Password Hashing Competition winner): tunable memory + time, actually memory-hard — GPUs and ASICs pay the memory cost; the modern recommendation for new systems when the library support is solid (it now is across the ecosystem). scrypt: the interim memory-hard choice, still sound, between the two in adoption. The decision: existing bcrypt deployments — stay (migration churn beats the marginal gain), verify cost is 12+; new systems — Argon2id with memory set to what your login budget allows (64MB+ class). And the non-choice that is still everywhere: PBKDF2-SHA256 with high iterations — acceptable per NIST, weakest of the three per unit of latency; legacy FIPS-constrained environments only.

Password reset vs password verify: two bcrypt operations, two budgets

The latency budget differs by 100x: interactive login tolerates 250ms (user waits once); bulk verification (importing users, migrating hashes, cracking-adjacent internal audits) at 250ms each means hours for a million rows — parallelize across cores and accept the time, or stage the work. The anti-pattern that surfaces in audits: lowering the cost factor "for the migration script" and forgetting to raise it back — the production hash function now runs at cost 8. Config discipline: one definition of the cost factor, loaded from environment, referenced everywhere; a second hard-coded value in a migration script is a finding waiting to be written.

Implementer's note

This site’s tool uses bcryptjs in the browser: hashSync / compareSync with a rounds slider (4–14 in the UI; high rounds can freeze the tab for seconds — that cost is the point). Production servers should measure cost on their CPU, not on a laptop fan. The 72-byte truncation is a bcrypt algorithm property, not a UI bug — UTF-8 passwords can hit the ceiling earlier than “72 characters”. Versions $2a$ / $2b$ / $2y$ are largely interoperable for verify; generate $2a$/$2b$ from a maintained library and do not hand-edit the prefix.

FAQ

Bcrypt or Argon2id for a greenfield app?

Argon2id won the 2015 Password Hashing Competition and is memory-hard (GPU/ASIC pay for RAM). Bcrypt remains a sound, ubiquitous choice. For greenfield with solid library support, Argon2id is the modern default; existing bcrypt rows do not need a flag-day migration if cost is already ≥12.

Why Does Bcrypt Produce Different Hashes Each Time?

Bcrypt automatically generates a random salt per hash. Even with the same input password, the output hash differs. Verification works by re-computing with the stored salt.

What Cost Factor Should I Choose?

Pick a value that makes user login take 100-300ms on production hardware. In 2026 that often means 12–13. Raise gradually via login-time rewrite as machines get faster.

This article is brought to you by ToolVault. More developer tools at the homepage.