bcrypt Hash & Verify

about this tool

Slow on purpose

Most hashes are built to be fast. bcrypt is built to be slow, because the thing it protects against is someone who has stolen your database and is trying billions of guesses against it offline. A hash that takes a quarter of a second is barely noticeable when someone signs in and ruinous when someone is guessing.

The cost factor sets how slow. Each step doubles the work, so cost 12 is a thousand times slower than cost 2 and four times slower than cost 10. Pick the highest number your sign-in path can afford, then raise it again in a few years as hardware improves.

Every hash is different

Hash the same password twice and you get two different results, because a random salt goes into each one. That is deliberate: it means two users with the same password have different hashes, and a precomputed table of common passwords is useless.

The salt is not a secret. It is stored inside the hash itself, which is why a bcrypt hash is self-contained: the version, the cost, the salt and the digest all travel together in one string, and verifying needs nothing else.

The 72-byte limit

bcrypt reads at most 72 bytes of a password and silently ignores the rest. Anything beyond that point contributes nothing, so a 200-character passphrase is no stronger than its first 72 bytes, and two long passwords sharing an opening will both verify against either hash.

Bytes, not characters: an accented letter is two bytes and an emoji is four, so a password can hit the limit sooner than it looks. The counter above shows where you are.

Do not paste a real password here

Everything happens in this page and nothing is transmitted. That is still not a good reason to type a live credential into a website. Use this for understanding a hash, generating a test fixture or checking a cost factor, and use a local tool for anything real.

For a digest of a file or a piece of text, use the hash generator — but not for passwords, which is what this tool is for. To produce a password worth hashing, see the password generator.

Apache and nginx basic auth use bcrypt for the same reason, and the htpasswd generator produces a .htpasswd file with the server config to go with it.

questions

What cost factor should I use?

12 is a sensible default in 2026, and the tool shows how long each hash actually took on your machine so you can judge. The cost is a power of two, so 13 is twice the work of 12; aim for something the login path can afford but an attacker cannot repeat billions of times.

Why are two hashes of the same password different?

Because bcrypt generates a random salt for each hash and stores it inside the result. That is the point: identical passwords produce different hashes, so a leaked database cannot be scanned for repeated values. Verification reads the salt back out of the hash.

Does bcrypt really ignore anything past 72 characters?

Yes, and it is a real trap. bcrypt truncates the password at 72 bytes, so a longer passphrase is silently cut and the discarded part does nothing. The tool warns when your input is over the limit; note that bytes and characters differ once you leave ASCII.

Can a bcrypt hash be decrypted?

No. Hashing is one-way, so the only way back is to guess passwords and hash each one — which is exactly what the cost factor is designed to make slow.

What do the parts of a bcrypt hash mean?

A hash such as $2b$12$… encodes the algorithm version, the cost factor and the salt before the digest itself. Paste one in and each part is read out for you, which is how you check what cost an existing system was using.