Bcrypt Hash Generator & Verifier

Everything runs in your browser — passwords and hashes never leave this page. Each hash embeds a random salt, so hashing the same password twice gives different (equally valid) hashes: that is bcrypt working as designed. Cost 10–12 is the common production range in 2026; each +1 doubles the work for you and for an attacker. High costs (13–14) can take seconds in a browser tab.

bcrypt reads 72 bytes and throws the rest away

The limit comes from the Blowfish key schedule bcrypt is built on, and it is measured in bytes after the text is encoded — not in characters. Seventy-two letters fit exactly; the seventy-third is discarded, silently, by both the hasher and the verifier. Two passwords sharing a 72-byte prefix produce the same hash and verify each other, and nothing anywhere says so.

A generated hundred-character password loses its last twenty-eight characters entirely — which makes this a problem for exactly the people who thought they were being careful. A passphrase of a dozen ordinary words is usually well under the limit and is fine. The cut never leaves half a character behind, and anything short passes through untouched.

Which means eighteen emoji and nineteen emoji are the same password

Because the limit is in bytes, it arrives sooner for anything outside the Latin alphabet. A password in a wider script runs out of room while it still looks short:

Eighteen emoji are exactly 72 bytes, so a nineteenth is invisible: hash the eighteen-emoji password and the nineteen-emoji one verifies against it. Not similar — identical. A password in Chinese hits the cap at twenty-four characters where an ASCII one has seventy-two to play with. All four widths happen to divide 72 exactly, which is a coincidence of 1, 2, 3 and 4 rather than a design.

Fewer characters is not automatically less security, though, because a character drawn from a larger set carries more of it. Putting rough alphabet sizes against each cap — assumptions rather than measurements, so treat these as illustrative: 72 ASCII letters at about 473 bits, 36 Accented Latin at about 275 bits, 24 Chinese at about 283 bits, 18 Emoji at about 195 bits. ASCII does allow the most, since one byte per character goes furthest — but by 2.4×, not the 4× the character counts imply. The ordering is not the character ordering either: Chinese fits fewer characters than accented Latin and carries more, because it is choosing from a far larger set. Every one of those caps clears the 186 bits the digest itself carries, though the emoji one only just — about 9 bits of headroom. So the truncation is a correctness surprise, two passwords you believe are different turning out not to be, rather than a security ceiling anyone was pressed against.

The cost number is an exponent, not a count

Cost 12 does not mean twelve of anything. It means 2¹² = 4,096 rounds of key setup, so every notch on the slider doubles the work.

Two notches is always four times the work wherever you start, and cost 16 is sixty-four times cost 10. That asymmetry is the entire point of the design: a hash taking a quarter of a second is barely noticeable at a login prompt and ruinous to somebody trying a billion guesses. The attacker and the user pay the same multiplier, and only one of them is paying it once.

Every setting travels inside the hash

A bcrypt hash is 60 characters and every part of it is readable: 7 for the version and cost, 22 of salt, 31 of digest.

Because the salt rides along, verifying needs nothing but the password and the string — and hashing the same password twice gives two different 60-character results that both verify. If two users' hashes ever match, they did not merely choose the same password; something is wrong with the salt. Those 22 characters carry 128 bits. One last trap: bcrypt encodes with its own 64-character alphabet starting "./" where standard Base64 starts "AB". Paste a bcrypt hash into a general Base64 decoder and you get nonsense, and that is why.