bcrypt: the password hash that's slow on purpose

Every time you log in anywhere competently built, your password is not compared against a stored password — it is run through a password-hashing function and the result is compared against a stored hash. bcrypt, designed by Niels Provos and David Mazières in 1999, is the function that made this idea practical, and a stolen database full of bcrypt hashes is still a bad day rather than a catastrophe. Fast hashes like SHA-256 can be guessed billions of times per second on a GPU; bcrypt forces every single guess to do real, tunable work, which collapses an attacker's guessing rate to a crawl.

A bcrypt hash is a self-describing 60-character string: the $2b$ prefix names the algorithm variant, the two digits after it are the cost factor (the work is 2 to the power of that number, so each step doubles the time), and the rest packs a 16-byte random salt and the resulting digest. Because the salt and cost travel inside the hash itself, verifying a password needs nothing but the hash — re-run bcrypt with the same salt and cost and see if the digest matches. This tool does both directions in your browser: generate fresh hashes with an adjustable cost, and check passwords against existing $2a$, $2b$ or $2y$ hashes.

Open the free bcrypt — no signup, runs entirely in your browser.

How to use it

1. Pick Hash password to generate, or Verify hash to check a password against an existing hash.
2. Type the password — the counter underneath shows its UTF-8 byte length and warns past bcrypt's 72-byte ceiling.
3. For hashing, set the cost factor with the slider; the estimate next to it shows roughly how long one hash takes on your device.
4. Click Generate or Verify and wait a moment — the pause is the security feature, not a bug.
5. Copy the resulting $2b$ hash, or read the verdict: match, no match, or a specific explanation of what is wrong with the pasted hash.

Why this one

• Honest about bcrypt's quirks: live 72-byte truncation warnings, NUL-character notices, and a hard refusal of unreliable $2x$ hashes instead of silently wrong answers.
• Device-calibrated timing: after your first hash, cost estimates reflect your actual hardware, so you can pick a cost factor with feel rather than folklore.
• Specific parse errors for malformed hashes — bad prefix, wrong length, invalid characters — so a mangled paste never masquerades as a wrong password.
• Zero network involvement: WebAssembly in a background worker does the work locally, and passwords are never transmitted anywhere.

Frequently asked questions

Can you decrypt a bcrypt hash?

No. bcrypt is a one-way function — there is no decryption key and no reverse algorithm, by design. The only way to find the password behind a hash is to guess candidates and re-hash each one at the hash's full cost until a digest matches. That is exactly what the Verify tab does for a password you already suspect; recovering an unknown password means repeating that process possibly billions of times, which is precisely the protection bcrypt provides.

What is the difference between $2a$, $2b$ and $2y$?

$2a$ is the original OpenBSD prefix. After a wraparound bug was discovered in crypt_blowfish's implementation, $2b$ was introduced for hashes produced by fixed code — it is the current standard and what this tool generates. $2y$ is PHP's marker for the same fixed behavior, so $2b$ and $2y$ hashes verify identically. You may also encounter $2x$ in old databases: it marks hashes from the buggy version, which cannot be verified reliably — the only safe fix is to re-hash those passwords.

Why does bcrypt ignore everything after 72 bytes?

It is a hard limit in the algorithm's design: bcrypt's key schedule only consumes the first 72 bytes of password material, and anything beyond is silently discarded. Note bytes, not characters — with multibyte UTF-8 (accented letters, CJK, emoji), 72 bytes can be far fewer than 72 characters. The practical consequence: two different passwords that share their first 72 bytes produce identical hashes, so length past that point adds nothing. This tool counts bytes live and tells you exactly when truncation kicks in.

What cost factor should I use?

Cost 10 is the common default; each step up doubles the work, so 12 is four times harder than 10. The right target is the highest cost that keeps a single hash under roughly a quarter of a second on your server — slow enough to hurt attackers guessing in bulk, fast enough that users never notice one login. Costs above 14 are impractical in a browser tab, which is why this tool caps there.