bcrypt Generator & Verifier

Create and verify bcrypt password hashes – and see what such a hash is actually made of. Everything runs locally in your browser.

How a bcrypt hash is built

A bcrypt hash is not an opaque blob but a clearly structured format – the so-called Modular Crypt Format. It is always 60 characters long and consists of four parts separated by $:

$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewKyJ.NfBu4nEqfa
└──┘└─┘└────────────────────┘└─────────────────────────────┘
  │  │            │                         │
  │  │            │                         └── Digest (31 chars = 23 bytes)
  │  │            └── Salt (22 chars = 16 random bytes)
  │  └── Cost factor: 2^12 = 4,096 rounds
  └── Version identifier

The version identifier states which flavour was used. $2b$ is today's standard, $2a$ the long-standing predecessor and $2y$ a marker introduced by PHP. For passwords as bcrypt processes them, all three compute identically.

The cost factor is the single most important value: it is a base-2 logarithm. At 12, key derivation runs 2¹² = 4,096 rounds. Every step up doubles the computation time – barely noticeable for you when logging in once, but the decisive cost for anyone wanting to try billions of passwords.

The salt is 16 random bytes encoded in bcrypt's own Base64 alphabet (./A–Za–z0–9) – not the one from RFC 4648. It sits in the hash in the clear and is not a secret either: its job is to make sure two users with the same password still get completely different hashes, and that precomputed rainbow tables are worthless.

The digest, finally, is the actual result: 23 of the 24 computed bytes. That the last byte is dropped is a quirk of the original OpenBSD implementation which has remained part of the format to this day.

Which cost factor should I pick?

The common recommendation today is at least 10, usually 12. The right value depends on your hardware rather than on a fixed number: as a rule of thumb, pick the highest cost factor at which a login on your production server still takes roughly 250 to 500 milliseconds. Because hardware keeps getting faster, that value should be raised every few years – good systems rehash a password automatically on the next successful login.

FAQ

Can a bcrypt hash be reversed?
No. bcrypt is not encryption but a one-way function – there is no key that would bring the password back. Verifying always means: run the entered password through the same salt and the same cost factor again and compare the results. That is exactly what the verify mode above does.

Why do I get a different hash every time for the same password?
Because a new random salt is used for every computation. That is intended, not a bug – verify mode still recognises the password, because the salt ships inside the hash.

Why is my long password cut off?
bcrypt only processes the first 72 bytes. Anything beyond that no longer affects the result – two passwords that differ only from byte 73 onwards produce the same hash. With accented characters and emoji that limit arrives sooner than it looks, because one character takes several bytes. If you want to allow very long passphrases, Argon2 serves you better.

bcrypt or Argon2?
Argon2id is considered the first choice for new systems today, because on top of computation time it also drives up memory usage, which slows down attacks using graphics cards and special-purpose hardware. That does not make bcrypt insecure: it has been in use since 1999, is thoroughly studied and perfectly fine for existing systems. For Argon2 there is a dedicated tool at argon2.rellit.de.

Is my input uploaded anywhere?
No. The computation is done by a WebAssembly module directly in your browser. There is no server that could see your password or your hash. Still: real production passwords do not belong in any web tool, including this one.