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.