Bcrypt hash generator

Create and verify Bcrypt hashes.

Text (password) Cost (rounds)

Verify Hash

Plaintext bcrypt hash

Higher cost is slower but safer (12+ may take several seconds). All processing happens only in your browser.

You are building a login form and you need to store passwords — but not the passwords themselves. Or you are debugging an auth bug and want to know whether the hash in your database really matches the password a user typed. This tool does both: it produces a bcrypt hash at the cost factor you choose, and it verifies a plaintext string against a hash you paste in.

How it works

Generating a hash

Type the string you want to hash into Text (password) and pick a Cost (rounds) value from the dropdown — 8, 10, 12 or 14. Press Generate Hash and the result appears in the output box, ready to copy.

A bcrypt hash is self-describing. A result like $2a$10$N9qo8uLOickgx2ZMRZoMye... breaks down as:

Part	Meaning
$2a$	Algorithm version identifier
`10$`	Cost factor (2^10 = 1,024 key-expansion rounds)
next 22 chars	The salt, generated randomly for you
remainder	The hash itself

Because the salt is embedded, the same input produces a different hash every time you press the button. That is expected — it is why bcrypt resists rainbow-table attacks. It also means you cannot compare two hashes to each other.

Choosing a cost factor

Each step up doubles the work. The OWASP Password Storage guidance (checked at the time of writing) sets a minimum work factor of 10 and suggests 12 or higher for new systems. Higher is safer but slower — cost 14 can take several seconds in a browser, and your login endpoint pays that cost on every sign-in. Set it as high as your server can tolerate.

Verifying a hash

Put the original string in Plaintext, paste the stored hash into bcrypt hash, and press Verify. The tool re-derives a hash using the salt and cost already encoded in the hash you supplied, then compares. A match confirms the plaintext is the one that produced that hash.

Note: bcrypt truncates input beyond 72 bytes in most implementations, so anything past that point is ignored. All hashing here happens locally in your browser — nothing is uploaded — but for real production secrets, hash on your own server rather than in any web page.

Terms explained

Cost (rounds): The work factor. The number of key-expansion iterations is 2 raised to this value, so cost 12 is four times the work of cost 10.
Salt: Random data mixed into the password before hashing. bcrypt generates it for you and stores it inside the resulting hash string.
Plaintext: The original, unhashed string — the thing a user actually types into a password box.
Verify: Re-running the hash with the salt and cost taken from an existing hash, to test whether a plaintext matches it.
$2a$ / $2b$: Version prefixes for the bcrypt format. They mark which revision of the algorithm produced the hash.

Frequently asked questions

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

bcrypt generates a fresh random salt on every run and embeds it in the output, so the resulting string differs even for identical input. This is intentional and does not mean anything went wrong. To check a password, use the Verify box rather than comparing two hashes visually.

Can I turn a bcrypt hash back into the original password?

No. bcrypt is a one-way hash, not encryption, so there is no key that reverses it. The only way to test a candidate password is to hash it again with the same salt and compare — which is exactly what the Verify function does.

Which cost factor should I use?

Current OWASP guidance sets 10 as a floor and recommends 12 or more for new applications. Benchmark on your own hardware: pick the highest value where a single hash still completes in a fraction of a second on your login server.

Is my password sent to your server?

No. The hashing library runs entirely in your browser and nothing you type is transmitted or stored. Even so, treat this tool as a learning and testing aid, and generate production credentials in your own environment.

Does bcrypt have a length limit?

Yes. Most implementations only use the first 72 bytes of the input and silently ignore the rest, so very long passphrases are effectively truncated. If you need to support longer inputs, pre-hash them or use a modern alternative such as Argon2id.