Bcrypt

Hash and verify strings using bcrypt

Generate a bcrypt hash with salt rounds, or compare plaintext against an existing hash

Last updated: January 22, 2026

CreatorFrank Zhao

Hash

Your string

Salt count

Bcrypt uses cost factor rounds in the range 4–31 (values outside are clamped).

Bcrypt hash

—

Compare string with hash

Your string

Your hash

Do they match?—

Bcrypt is a password hashing algorithm designed to be intentionally slow. That “slowness” is a feature: it makes brute-force guessing much more expensive. This guide shows how to use the Bcrypt tool for hashing and comparing strings, how to interpret the result, and how to choose sensible salt rounds.

→Introduction / Overview →How to Use / Quick Start →Real-World Examples →Common Scenarios →Tips & Best Practices →Calculation Method →Related Concepts →Frequently Asked Questions →Limitations / Disclaimers →External References

Introduction / Overview

This Bcrypt tool helps you do two practical things:

Hash: create a bcrypt hash from a string using a chosen cost (salt rounds).
Compare: verify whether a plaintext string matches an existing bcrypt hash.

Conceptually, bcrypt hashing looks like:

h = \mathrm{bcrypt}(m,\ \mathrm{salt},\ c)

where $m$ is your message (often a password), $\mathrm{salt}$ is random per-hash, and $c$ is the cost factor (“salt rounds”).

Who typically uses this?

Developers verifying login flows and password hashing settings
Security engineers sanity-checking cost factor choices
Anyone migrating hashes between systems and needing quick verification

A quick reliability note

Hashing and comparison run locally in your browser. If you enable “share with results”, the plaintext can be included in the URL, so it’s best to avoid sharing when working with sensitive inputs.

If you need random strings (API keys, invite codes), pair this with our Token Generator. If you need fast digests for non-password use cases, try Hash Text.

How to Use / Quick Start

1
Type the string you want to hash in the “Hash” section.
2
Choose a Salt count (cost factor). A common starting point is 10–12.
3
Copy the resulting bcrypt hash and store it (never store the plaintext).
4
To verify later, paste plaintext + stored hash into the “Compare” section and check whether they match.

Example A: understanding salt rounds

Bcrypt cost is exponential. If you change the cost from $c_1$ to $c_2$ , the expected work scales roughly by:

\text{factor} \approx 2^{(c_2 - c_1)}

For a concrete case, going from 10 to 12 rounds increases the work by about:

2^{(12-10)}

=

2^{2}

=

4

That’s why “just +2” can be a big change. Use rounds to balance security with acceptable login latency.

Example B: reading the compare result

Suppose you stored a bcrypt hash $h$ for some plaintext $m$ . Later, you check a login attempt $m'$ . The “Compare” section answers:

\text{match}

=

\text{bcrypt}(m', \text{salt}, \text{cost})

=

h

If the tool says Yes, then $m'$ matches the original plaintext. If it says No, the plaintext is different (or the hash is malformed).

Real-World Examples / Use Cases

Password storage in a web app

Scenario: You are building a signup flow and you want to store passwords safely.

Inputs: plaintext $m$ (user password), rounds $c = 12$ .

Result: a bcrypt hash string $h$ (it will look like $\$2b\$12\$\dots$ ).

How to use it: store $h$ in your database, and when the user logs in, compare the login plaintext to the stored hash.

Tuning performance vs security

Scenario: Your login feels slow in production.

Inputs: test costs $c = 10, 11, 12$ .

Result: relative work grows roughly as $2^c$ . A single step (e.g., 11→12) is ~2×.

How to use it: pick the highest cost that keeps p95 login time acceptable for your system.

Verifying imported hashes

Scenario: You migrated users from another system and imported bcrypt hashes.

Inputs: known test password $m = \text{"test123"}$ and imported hash $h$ .

Result: “Do they match?” should return $\text{Yes}$ for the test account.

How to use it: if compare fails, double-check version prefixes (e.g., $\$2a$ , $\$2b$ ) and whether the original system used a different hash format.

Backend integration test

Scenario: You want to ensure your backend bcrypt library matches browser output.

Inputs: plaintext $m$ , cost $c$ .

Result: bcrypt hashes differ each time due to random salt, but compare should still return $\text{Yes}$ .

How to use it: generate a hash in one environment and verify in the other.

If you’re building a complete authentication experience, bcrypt is only one piece. You might also want a secure token generator for password resets or session identifiers.

Helpful companion tools: Token Generator, Hash Text.

Common Scenarios / When to Use

Choosing rounds for production

Use this when you’re deciding on a default cost factor and want to reason about how changes affect compute time.

Debugging a login mismatch

Use Compare to verify whether the stored hash matches what the user typed, without changing any database values.

Migration sanity checks

Confirm imported bcrypt hashes still validate known test passwords after a user migration.

Teaching and documentation

Show teammates why bcrypt outputs change each run and why salt is essential.

Client-side prototypes (carefully)

For demos and prototypes, hashing in-browser can be convenient, but avoid shipping client-only auth logic to production.

Generating non-password digests

If you really just need a fast digest, bcrypt is usually not the right tool — consider Hash Text instead.

When bcrypt might not be the best fit

You need hashing for file integrity (use SHA-256/SHA-3 in Hash Text)
You need a short random token (use Token Generator)
You must comply with strict policies that forbid entering secrets into a browser tool

Tips & Best Practices

Never expect identical hashes for the same password
Bcrypt includes a random salt by default, so hashing the same plaintext twice produces different-looking hashes. That is normal.
Treat rounds as a performance knob
Raising cost improves resistance to guessing, but can increase CPU usage. Small changes matter because cost is roughly exponential.
Validate end-to-end with compare
When integrating with a backend, test by generating a hash in one environment and verifying in the other. Compare is the real compatibility check.
Avoid sharing secrets
The Share modal can include plaintext in the URL if enabled. For sensitive values, keep sharing disabled or clear the inputs first.

Tip for documentation: if you’re writing onboarding docs for your team, include a small “known test” account (with a non-sensitive password) and use this tool to demonstrate how compare works.

If your docs also mention API keys or reset tokens, generating realistic examples is easier with Token Generator.

Calculation Method / Formula Explanation

Unlike simple hash functions (SHA-256, SHA-3), bcrypt is designed specifically for password hashing. It is intentionally expensive, and its “cost factor” controls how expensive each hash computation is.

A common way to explain bcrypt cost is to treat the expected work as roughly proportional to:

\text{work}(c) \propto 2^c

and an approximate time model as:

t(c) \approx k\,2^c

where $k$ depends on your device and implementation.

\frac{t(c_2)}{t(c_1)}

\approx

\frac{k\,2^{c_2}}{k\,2^{c_1}}

=

2^{(c_2-c_1)}

Variables you’ll see in this guide:

$m$ : plaintext input (the string you type)
$h$ : bcrypt hash output (stored value)
$c$ : cost factor / salt rounds

Related Concepts / Background Info

Salt

A random value mixed into the hash so the same password does not produce the same stored output. It also helps defend against precomputed “rainbow table” attacks.

Cost factor

The knob that controls how slow hashing is. Because cost is roughly exponential, raising cost makes offline guessing much more expensive.

Password hashing vs general hashing

SHA-256 is great for integrity, but too fast for passwords. Password hashes aim to be slow so attackers cannot try billions of guesses per second.

Verification

You never decrypt bcrypt hashes. You verify by hashing the candidate password using the salt and cost embedded in the stored hash, then comparing.

If you’re explaining “hashing” to a non-security audience, it can help to contrast bcrypt with a standard digest: a digest is typically used for equality checks and integrity; bcrypt is used for password storage.

For digest-style hashing, use Hash Text.

Frequently Asked Questions (FAQs)

Why does the hash change every time I click around?

Because bcrypt uses a random salt. Even for the same plaintext $m$ and cost $c$ , the salt changes, so the stored string looks different. Verification still works because the salt is embedded in the hash.

What are “salt rounds” in practical terms?

Think of rounds as a dial that increases compute work roughly like $2^c$ . Increasing cost by 1 is about 2× more work.

What rounds should I choose?

There isn’t one universal number. A reasonable approach is: pick the highest cost where your login remains smooth on your slowest server and typical client devices. Use the scaling idea $2^{(c_2-c_1)}$ to understand tradeoffs.

Is bcrypt reversible?

No. You do not “decrypt” bcrypt hashes. You verify by recomputing with the embedded salt/cost and comparing.

Can I use bcrypt for file checksums or API signatures?

Usually no. It’s intentionally slow and designed for passwords. For integrity checks and signatures, use a standard digest like SHA-256 or SHA-3 (see Hash Text).

Does this tool send my input to a server?

The hashing and comparison run in your browser. However, always treat web tools with care: if you enable “share with results”, your plaintext may be placed in the URL.

Why does compare return “No” when I paste a strange hash?

If the hash is malformed or uses an unsupported format, compare can fail. Try pasting the full hash string (including the prefix) and confirm it begins with something like $\$2a\$$ , $\$2b\$$ , or $\$2y\$$ .

Limitations / Disclaimers

This tool is for educational and development use. It does not replace a full security review or professional advice.
Avoid entering real production passwords on any third-party website. Use synthetic test strings whenever possible.
Performance depends on your device. Costs that feel fine on a laptop may be too slow on mobile (and vice versa).
“Salt count” in this UI is a convenience. Bcrypt implementations clamp cost to the supported range (commonly 4–31).

External References / Sources

OpenBSD bcrypt (background and history)
https://man.openbsd.org/bcrypt
OWASP Password Storage Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
bcrypt.js (JavaScript implementation used in many tools)
https://github.com/dcodeIO/bcrypt.js

Related Calculators

Chronometer

Use a simple chronometer (stopwatch) to track elapsed time down to milliseconds. Runs locally in your browser.

Try Now

Email normalizer

Normalize email addresses to a standard format for easier comparison. Useful for deduplication and data cleaning. Runs locally in your browser.

Try Now

ETA calculator

Estimate the time needed to consume a total amount at a constant rate, and get an expected end time. Runs locally in your browser.

Try Now

JWT parser

Parse and decode your JSON Web Token (JWT) and display its content. All computation runs locally in your browser.

Try Now

MIME types

Know which file extensions are associated to a MIME type, and which MIME type is associated to a file extension. Includes a full MIME types table.

Try Now

Lorem ipsum generator

Generate random Lorem Ipsum placeholder text with customizable paragraphs, sentences, and word counts. Runs locally in your browser.

Try Now