Bcrypt Generator & Verifier
Generate a bcrypt hash from a password at any cost factor, or verify a password against an existing hash. It shows the version ($2a / $2b / $2y), the cost factor and the salt, and times every hash. Everything runs in your browser; nothing is uploaded.
Hashing and verification happen entirely in your browser — nothing is uploaded. The password, salt and hash never leave this page.
Use bcrypt for passwords, not for data. bcrypt is a deliberately slow, salted password-storage hash — the salt is baked into the output and the cost factor makes brute-forcing expensive. That is the opposite of the fast MD5/SHA-256 digests on our Hash Generator, which are built for speed and are the wrong choice for storing passwords.
$2$, $2a$, $2b$, $2x$, $2y$.What this tool is
- A free, in-browser bcrypt generator and verifier: hash a password at a chosen cost factor, or check a password against an existing bcrypt hash.
- Generate produces a standard $2b$ hash with a random 128-bit salt baked in; the cost slider (4–15) controls the work factor, and the tool shows how long each hash took.
- Verify uses bcrypt.compare to tell you Valid or Invalid — the correct way to check a password, since every bcrypt hash of the same password is different.
- An anatomy readout breaks any hash into its version ($2a/$2b/$2y), cost factor and salt, so you can read what a stored hash actually contains.
- Everything runs client-side with bcryptjs — the password, salt and hash never leave your browser.
What is bcrypt, and why a deliberately slow hash?
Bcrypt is a password-hashing function built on the Blowfish cipher. Its whole purpose is the opposite of a normal hash: where MD5 or SHA-256 are engineered to be as fast as possible, bcrypt is engineered to be slow — and adjustably so. That matters because the people attacking a leaked password database want to try billions of guesses per second. A fast hash lets them; a slow, salted hash does not.
Salt — why every hash is unique
Bcrypt generates a random 128-bit salt for every password and stores it right inside the output string. Because the salt differs each time, two users with the same password get two completely different hashes, and an attacker can't precompute a rainbow table that works against everyone at once — they have to attack each hash separately. It also means the same password hashed twice will never produce the same string, which is why you verify with a compare function, not by re-hashing and comparing text.
Cost factor — the work factor you control
The cost factor (the 10 in $2b$10$…) is a power of two: cost 10 means 210 = 1,024 key-setup rounds, cost 12 means 4,096. Each step doubles the CPU work to compute one hash. You tune it so a single hash takes roughly 50–250 ms on your real hardware — slow enough to make offline cracking painful, fast enough that logging in feels instant. And because the cost is embedded in the hash, you can raise it over time: when a user next logs in, verify against their old hash, then re-hash the password at the new, higher cost and store that.
bcrypt vs scrypt vs Argon2 vs SHA-256
- SHA-256 / MD5 are the wrong tool. They are general-purpose, blazing-fast and unsalted by default — exactly what you do not want for passwords. GPUs can try tens of billions of SHA-256 guesses per second. Use them for integrity and fingerprints, never for password storage.
- bcrypt adds a salt and a tunable cost factor, which is why it has protected passwords well for two decades. Its limits: it ignores anything past the first 72 bytes of a password, and being low-memory it is comparatively cheap to attack with GPUs/ASICs.
- scrypt adds a memory-hardness parameter, making large parallel attacks expensive in RAM as well as CPU — a step up from bcrypt against custom hardware.
- Argon2id is the modern default recommendation (OWASP): memory-hard, side-channel resistant, with separate time, memory and parallelism knobs. For a brand-new system, prefer Argon2id; keep bcrypt for existing systems or where Argon2 isn't well supported.
$2a vs $2b vs $2y
The $2a$, $2b$ and $2y$ prefixes are version markers. $2a$ is the long-standing OpenBSD/standard form; $2b$ is the current standard that fixed a 2014 length-handling bug; $2y$ comes from the crypt_blowfish / PHP world and is equivalent to $2b$. Hashes are cross-compatible for verification — a $2a$ hash verifies fine with a $2b$ implementation. This tool emits $2b$ and reads all of them.
When to re-hash: raise the cost factor when your hardware gets faster, or migrate to Argon2id, by re-hashing each password at the next successful login (you have the plaintext at that moment). Never try to "upgrade" a stored hash without the password — you can't, and that's by design.
Frequently asked questions
What is bcrypt?
Bcrypt is a password-hashing function designed by Niels Provos and David Mazières in 1999, based on the Blowfish cipher. Unlike general-purpose hashes such as MD5 or SHA-256, bcrypt is deliberately slow and includes a built-in, randomly generated salt and an adjustable "cost factor" (work factor). Those properties make it well suited for storing passwords: the salt defeats precomputed rainbow tables because every hash is unique even for identical passwords, and the cost factor lets you make each hash take a configurable amount of CPU time, so that offline brute-force and dictionary attacks become expensive. A bcrypt hash is a self-contained 60-character string that records the algorithm version, the cost factor and the salt alongside the digest, so verifying a password needs nothing but the hash itself.
What cost factor should I use?
The cost (or work) factor is a power of two: a cost of 10 means 2^10 = 1,024 key-setup iterations, cost 12 means 4,096, and so on — each step up doubles the work. The right value is whatever keeps a single hash at roughly 50–250 milliseconds on your production hardware, because that is slow enough to frustrate attackers but still fast enough to not degrade login. 10 is a common, sensible default; 12 is a frequently recommended modern baseline on server hardware. Benchmark on the machine that will actually run it, and plan to raise the cost over time as hardware gets faster — bcrypt makes this easy because the cost is stored in the hash, so you can re-hash at a higher cost the next time each user logs in.
Is bcrypt still secure in 2026?
Bcrypt remains a solid, widely trusted choice for password storage when used with an adequate cost factor. Its main limitations are that it only considers the first 72 bytes of a password and that, unlike memory-hard functions, it is relatively cheap to attack with GPUs and ASICs because it uses little memory. For new systems, modern guidance (including OWASP) points first to Argon2id — a memory-hard, side-channel-resistant function that is the current preferred default — with bcrypt and scrypt as acceptable alternatives, especially where an Argon2 implementation is not available. In short: bcrypt is not broken and is far better than any fast hash, but if you are choosing fresh, prefer Argon2id and reserve bcrypt for existing systems or environments where it is the best supported option.
Why is a bcrypt hash different every time, and how do I verify a password?
Because bcrypt generates a new random salt for every hash, hashing the same password twice produces two different 60-character strings — this is intentional and is what makes rainbow tables useless. It also means you cannot verify a password by hashing it again and comparing strings. Instead you use bcrypt's compare function: it reads the salt and cost factor out of the stored hash, re-hashes the candidate password with exactly those parameters, and checks whether the result matches. This tool's Verify mode does precisely that with bcrypt.compare, entirely in your browser, and returns a clear Valid or Invalid verdict.