Bcrypt Generator + Verifier
Generate bcrypt hashes at any cost factor and check a password against an existing hash — the password never leaves this device.
Press ? for shortcuts · Never stored — a password is a credential. This page keeps nothing between visits. · Link carries settings only — never passwords or hashes.
This page loads no third-party code — no ads, no trackers, no analytics. Verify in your Network tab.
Do it offline:$ htpasswd -bnBC 12 "" "$PASSWORD" | cut -d: -f2
How to use it
- On the Hash tab, type or paste a password — the counter reports bytes and characters, with an amber chip past 72 bytes.
- Set the cost slider between 4 and 15 (default 12); the estimate readout times your own device, doubling per step.
- Press Hash (⌘/Ctrl + Enter), then copy or download the 60-character $2b$ result.
- On the Verify tab, paste a stored bcrypt hash — the breakdown labels its prefix, cost, salt and digest live.
- Enter the candidate password and press Verify: MATCH or NO MATCH, with a rehash chip on low-cost hashes.
Hash a password with bcrypt at any cost factor from 4 to 15, or check a candidate password against a stored hash for a plain MATCH or NO MATCH verdict. Both run in your browser through WebAssembly — the password never leaves this device, and this page keeps nothing between visits. A counter tracks UTF-8 bytes as you type, and a calibrated readout estimates each run before you commit.
How it works
Each run draws a fresh 16-byte salt from crypto.getRandomValues and encodes it into the output, so one password yields a new hash every run. The 60 characters decompose as $2b$, a two-digit cost, a 22-character salt, then a 31-character digest; verification reads the salt back out of the pasted hash and recomputes.
The cost is an exponent: bcrypt's EksBlowfish setup runs 2^cost key-schedule rounds, so each step doubles the work for you and for an attacker alike. The algorithm keys itself with at most 72 password bytes — the fourth example proves that cutoff.
On algorithm choice the page follows OWASP's Password Storage Cheat Sheet honestly: Argon2id is its first recommendation for new systems, and where bcrypt is in use it advises a work factor of 10 or more under the 72-byte limit. This tool emits $2b$ and verifies $2a$, $2b$, $2x$, $2y$.
Examples
correct horse battery staple$2b$12$Dnmof5J.MkfWQU6maJU0ZuryWJ41xfS5yeGpYEWyDNqKgodWqGA2aA real cost-12 run. Your output will differ — a fresh random salt enters every run — yet every such hash accepts the same passphrase.
$2b$12$Dnmof5J.MkfWQU6maJU0ZuryWJ41xfS5yeGpYEWyDNqKgodWqGA2aMATCHThe first example's hash, with the same passphrase as candidate. Nothing is decrypted — the tool recomputes from the embedded salt and compares digests.
$2y$04$I1q1sEvdR7a5olNrrn70A.IPj/flKsApjFHKARNM6N2daBL61oad6MATCH
cost 4 is far below current guidance — rehash on next loginA cost-4 $2y$ hash made by Apache htpasswd still verifies — old hashes stay checkable. The chip under the verdict quotes the tool's own wording for costs below 10.
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbcrypt only uses the first 72 bytes — characters beyond this do not affect the hashSeventy-two a's and one b: the amber chip fires, and the b truly vanishes — with the same salt, this input and its 72-byte prefix hash identically.
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Null bytes are refused, not swallowed
C implementations read the password as a C string and stop at the first U+0000, so systems disagree about what was actually hashed. This tool refuses and points at the character instead of joining the disagreement.
$2x$ marks a historical bug
crypt_blowfish coined $2x$ in 2011 to label hashes from its sign-extension bug with 8-bit characters. Verification here uses the corrected algorithm, so a genuine buggy-era $2x$ hash can honestly answer NO MATCH — a chip explains that before you distrust the password.
A $6$ line is SHA-crypt, not bcrypt
Shadow entries beginning $6$ get a refusal naming that format outright rather than a length complaint. An invented prefix like $2z$ is likewise named, never guessed at.
The 72 cap counts bytes, not characters
Seventy-two ASCII letters fit, but 24 three-byte CJK characters hit the cap too, so the counter shows both figures. The CLI line below truncates identically — htpasswd just emits a $2y$ prefix, which verifies here like any other variant. In reverse, htpasswd verifies $2a$ and $2y$ but rejects $2b$ — relabel this tool's output to $2y$ for .htpasswd files.
Common errors
Password is empty — this tool's bcrypt core refuses zero-length passwords, so there is nothing to hash. Enter at least one character.- bcrypt libraries disagree about zero-length passwords, so this page declines them outright on both tabs.
Password contains a null byte (U+0000) at character 5 — C-based bcrypt implementations stop reading there, so the same password would hash differently across systems. Remove it before hashing.- Fired by a password whose fifth character is U+0000; the position names the first null found.
A $6$ prefix marks SHA-512 crypt — that's SHA-crypt, not bcrypt. bcrypt hashes start with $2a$, $2b$, $2x$ or $2y$.- A shadow-file SHA-crypt entry landed in the hash field; the refusal identifies the real format.
$2z$ is not a bcrypt variant — bcrypt hashes start with $2a$, $2b$, $2x$ or $2y$.- An unknown prefix is rejected by name before any other check runs.
A bcrypt hash is exactly 60 characters — this input is 59. Check that the whole hash, and nothing else, was copied.- One character short — almost always a clipped copy; the count makes the loss visible.
Cost 32 is outside bcrypt's valid range — the two-digit cost must be between 04 and 31.- The two digits after the prefix must land in 04–31; hand-edited hashes trip this one.
Unexpected character "+" at position 60 — the salt and digest use only the bcrypt alphabet: . / A–Z a–z 0–9.- bcrypt's base-64 uses . and / rather than + — a plus means standard base64 or URL mangling crept in.
FAQ
Why is my bcrypt hash different every time?
Because a fresh random salt is drawn per run and written into characters 8–29 of the result, so the digest changes too. Each such hash accepts the original password — paste one into the Verify tab and it will MATCH. Identical hashes would mean a reused salt.
Is bcrypt still recommended for password storage?
It remains acceptable rather than first choice: OWASP recommends Argon2id for new systems and, for systems on bcrypt, a work factor of 10 or more with the 72-byte limit. This page defaults to cost 12 and flags verified hashes below cost 10 with a rehash chip.
What does the bcrypt cost factor actually do?
It is the exponent on the work: cost 12 runs 2¹² = 4,096 key-schedule rounds, and each step doubles the time for your hardware and an attacker's equally. Pick the highest cost your sign-in latency tolerates — the readout times your device first.
Keyboard shortcuts
- ⌘/Ctrl + Enter
- Run the active tab — hash or verify.
- ⌘/Ctrl + S
- Download the generated hash as a .txt file instead of saving the page.
- ⌘/Ctrl + C
- Copy the hash or verdict when nothing is selected and focus is in the tool — never the password.
- ⌘/Ctrl + Shift + C
- Copy the artifact even while a selection is active.
- ? or ⌘/Ctrl + /
- Open the shortcut help overlay.