Bcrypt Hash Generator

Hash and verify passwords with Bcrypt. Choose salt rounds from 8 to 14. Browser-only.

Bcrypt Hash Generator

Bcrypt is slow on purpose, and this page exposes the two operations that matter when you work with it: the Hash tab runs bcryptjs in your browser at the cost you pick from the salt-rounds selector (8, 10, 12, or 14), and the Verify tab checks a plaintext against an existing hash the way a login endpoint would.

Why the same password produces a different hash every time

Bcrypt generates a fresh random salt for every hash and embeds it in the output, so hashing hunter2 twice gives two different 60-character strings — and both are correct. The string is self-describing: $2b$ is the format version, two digits of cost, 22 characters of salt, then 31 of digest, all in bcrypt's own base64 variant.

This is why there is no compare-two-hashes workflow. Verification re-runs bcrypt using the salt and cost read out of the stored hash, which is what the Verify tab does. If you came from MD5 or SHA-256 expecting to check equality of two hash strings, this is the mental model to replace.

Picking a cost factor

The cost is an exponent: cost 10 means 2^10 = 1,024 internal rounds, cost 14 means 16,384. Measured in Node's JavaScript engine, a single hash took about 57 ms at cost 10 and about 809 ms at cost 14 — close to the 16x jump the round count predicts. Your login flow pays that price once per attempt; an attacker with a leaked database pays it for every guess. Pick the highest cost your latency budget tolerates: 10-12 is typical for interactive logins, and at 14 you will feel the pause on this page, since bcryptjs is pure JavaScript.

The 72-byte truncation

Bcrypt silently ignores everything past the first 72 bytes of input. Tested against the same library the page uses, a password of 72 a's followed by X verifies against the identical string ending in Y, while changing any character inside the first 72 breaks the match. The limit is bytes, not characters, so multibyte UTF-8 text hits it sooner — a real constraint if you accept long passphrases.

Hash 'hunter2' at cost 10
Input: hunter2
Output: $2b$10$0oEWEkIVdsNHZHlbn93Qf.BHzc1DPJDubRV6PkyY9JHd8UF6c./k6
Your output will differ — the random salt guarantees it. Every hash of hunter2 still verifies as a Match on the Verify tab.

Questions people ask

Two users pick the same password — will their stored hashes match?

No — that is the salt doing its job. Two users with the same password get unrelated hashes, which defeats precomputed rainbow tables. Paste either hash plus the original text into the Verify tab and both will report Match.

Can I decrypt a bcrypt hash back to the password?

No. Bcrypt is one-way: no key, no inverse. The only route back is guessing candidates and running each through bcrypt at the stored cost — exactly what the cost factor makes expensive.

MD5 and SHA-256 on this site are the wrong tools for passwords because they are fast; bcrypt is the storage-side complement to the password generator.

Further reading