Why does the output string contain the cost factor and salt, not just a hash?

That's bcrypt's key design decision: the encoded output ($2b$10$ ) embeds the algorithm version, cost factor, and salt directly alongside the hash itself. That means verifying a password later never needs a separate salt lookup, everything needed to re-run the same computation and compare is self-contained in the one stored string, which is why bcrypt hashes are safe to store as a single database column.

Why is bcrypt deliberately slow, and why does that matter?

Because slowness is the entire point for password storage. A fast hash like MD5 or SHA-256 (elsewhere in this category) can be brute-forced at billions of guesses per second on a GPU; bcrypt's cost factor controls a tunable number of internal rounds, so increasing it multiplies the time (and therefore the attacker's cost) per guess exponentially. Cost 10 already takes a noticeable moment even in an optimized WebAssembly implementation like this tool uses, that deliberate friction is the whole security model.

How should I choose a cost factor?

Higher is more secure but slower for both attackers and your own server; cost 10-12 is a common baseline for server-side authentication today, adjusted upward as hardware gets faster. This tool offers 4, 6, 8, and 10 specifically to let you feel that scaling directly since each increment roughly doubles computation time; costs above 10 get slow fast in a browser, which is why the tool caps there rather than offering higher values that could make the tab unresponsive.

Does this tool send my password to a server?

No. The bcrypt hash, including generating the random salt, is computed entirely in your browser via a WebAssembly module, so nothing you type here is transmitted anywhere. That said, avoid pasting a real production password into any online tool as a general habit, use this for learning, testing, or generating throwaway examples.

Bcrypt Hash Calculator - Generate a Bcrypt Password Hash

Overview

Introduction

Every other hash in this category is designed to be fast; bcrypt is deliberately, tunably slow, because for password storage, speed is a liability, not a feature.

This tool generates a bcrypt hash of any password you type, with a cost factor you control, computing a fresh random salt on every hash entirely in your browser.

What Is Bcrypt Hash Calculator?

Bcrypt is a password-hashing function designed by Niels Provos and David Mazières in 1999, based on the Blowfish cipher's key schedule, specifically built to be tunably slow rather than fast.

Its output is a single self-contained string encoding the algorithm version, cost factor, a 16-byte salt, and the resulting hash, e.g. $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy, so nothing extra needs to be stored alongside it to verify a password later.

How Bcrypt Hash Calculator Works

This tool generates a fresh random 16-byte salt via the browser's crypto.getRandomValues on every hash or regenerate, then runs your password and that salt through bcrypt's expensive key-setup phase (based on Blowfish's key schedule) for 2^costFactor iterations.

The result, algorithm version, cost factor, salt, and hash, is packed into bcrypt's standard encoded string format via hash-wasm's WebAssembly implementation, computed asynchronously since WASM calls return a Promise.

When To Use Bcrypt Hash Calculator

Use this to generate a bcrypt hash for testing an authentication system, learning how the cost factor affects computation time, or producing a throwaway example hash.

Don't paste a real production password into any online tool as a general habit; for actual application password storage, hash it server-side using a well-reviewed bcrypt library, not client-side JavaScript in a browser tab.

Often used alongside Bcrypt Hash Analyzer, MD5 Hash Calculator and SHA-256 Hash Calculator.

Features

Advantages

Deliberately, tunably slow, exactly the property a password hash needs that a fast general-purpose hash like MD5 or SHA-256 lacks.
Self-contained output format: cost factor and salt travel with the hash, so no separate salt storage or lookup is ever needed.
Decades of real-world scrutiny and remains a widely trusted choice for password storage today, alongside newer options like Argon2.

Limitations

Cost factor is capped at 10 in this tool's browser UI since higher values get slow fast and could make the tab unresponsive; production systems often use similar or higher values server-side where the environment is more predictable.
Bcrypt truncates passwords at 72 bytes; anything beyond that has no effect on the resulting hash, which can be a surprising gotcha for very long passphrases.
Newer memory-hard functions like Argon2 offer additional resistance to specialized hardware (ASIC/GPU) attacks that bcrypt doesn't provide as strongly.

Examples

Hashing a test password at cost factor 4 (fast, deterministic salt shown for illustration)

Input

hunter2

Output

$2a$04$.OGB/.SE/ueHAeqKBO2NC.DWhT18ajyuQbYD//ZCew1J6kBowToIW

A real bcrypt hash computed with hash-wasm at cost factor 4 and a fixed 16-byte salt for reproducibility; in the actual tool, the salt is freshly randomized on every hash, so running this twice normally produces two different-looking (but equally valid) hashes for the same password.

Best Practices & Notes

Best Practices

Never reuse a hash produced by pasting a real password into a browser tool as your actual stored credential; generate real application password hashes server-side.
Pick the highest cost factor your environment can tolerate in response time; this tool's 4/6/8/10 options let you feel how steeply the cost scales before choosing a production value.
Remember bcrypt truncates input past 72 bytes; don't rely on extremely long passphrases adding entropy beyond that point.

Developer Notes

Delegates to hash-wasm's WebAssembly bcrypt() implementation with outputType: 'encoded', following the same async useEffect pattern as this category's Whirlpool tool. A fresh 16-byte salt is generated via crypto.getRandomValues on mount and on every Regenerate click or cost-factor change, using the useEffect-after-mount trick (matching the Random JSON Object Generator's pattern) to avoid SSR/hydration mismatches from browser-only randomness.

Bcrypt Hash Calculator Use Cases

Generating a bcrypt hash to test an authentication system's password verification logic
Learning how bcrypt's cost factor affects computation time firsthand
Producing a throwaway example bcrypt hash for documentation or a tutorial
Comparing bcrypt's deliberately slow design against this category's fast general-purpose hashes

Common Mistakes

Using a fast general-purpose hash (MD5, SHA-256) for password storage instead of a dedicated slow hash like bcrypt.
Assuming two bcrypt hashes of the same password should match; they won't, because each uses a different random salt by design, that's expected and correct.
Choosing a cost factor without testing its real response-time impact; what feels instant at cost 4 can take a noticeable moment at cost 10.

Tips

Use the Bcrypt Hash Analyzer to parse an existing bcrypt hash's version, cost factor, salt, and hash components back out.
If you need to verify a password against a stored bcrypt hash rather than just generate one, that's a separate matching operation this tool doesn't perform, it only hashes.

Bcrypt Hash Calculator