bcrypt Hash & Verify

What is bcrypt?#

bcrypt is a password-hashing function built specifically to be slow on purpose. Where a fast hash like SHA-256 is designed to throughput megabytes per second, bcrypt is designed to cost real time per single guess — so that an attacker who steals a database of password hashes cannot try billions of guesses cheaply. It is the standard answer to “how should I store user passwords”: hash them with bcrypt, not with a plain SHA-256.

Two things make bcrypt fit for that job. First, it has a tunable cost factor that scales the work exponentially — raising the cost by 1 roughly doubles the time per hash, so hardware can be outrun by turning a knob. Second, it bakes a random salt into every hash, so identical passwords hash to completely different values and a precomputed table built for one database is useless against another. The salt and the cost are both carried inside the output string, so verification needs nothing beyond the password and the hash.

This page does both operations: hash a password into a bcrypt string, and verify a password against an existing hash. To keep the page responsive, hashing at cost 12 or above is offloaded to a Web Worker, so the heavy computation never freezes the interface.

How to use it#

1. Pick a mode: Hash (produce a bcrypt string from a password) or Verify (check a password against an existing hash).
2. Type the password. Click the eye icon to reveal it while typing; it is masked by default. UTF-8 is accepted, including emoji and non-Latin scripts.
3. In hash mode, set the cost slider (4–14, default 12). Higher is slower and stronger. A warning appears once the cost is high enough to take noticeable time.
4. In verify mode, paste the existing hash into the field that appears. The cost is read automatically from the hash itself — you do not set it.
5. Click the primary button. In hash mode the output is the bcrypt string; in verify mode the output is a clear match / no-match verdict, plus an elapsed-time readout that helps you judge the cost on your own hardware.

Key features#

• Tunable cost, 4–14. The default of 12 is the modern recommendation; each step roughly doubles the work, so you can keep pace with faster hardware over the years.
• Worker offload at high cost. Cost 12 and above runs in a Web Worker so the page stays responsive; if workers are blocked, it transparently falls back to the main thread with the same result.
• Built-in salt. Every hash gets a fresh random salt encoded into the output, so the same password never hashes twice to the same string.
• Verify with automatic cost. The cost factor is parsed out of the hash you paste, so there is no mismatch between how a password was hashed and how it is checked.
• Zero upload. Hashing and verification happen locally; the password never leaves the page.

Worked example#

Below is a real hash of hunter2 at cost 12, produced by this very page. Because the salt is freshly random, hashing hunter2 again will give you a different string — but this one is genuine and verifiable: paste it into Verify mode, type hunter2, and the verdict is match.

$2b$12$DG/IWIDBmJlywamLdGno2.guEH5lGnQ1OTULdIGN8BH1vqiLIGzjy

Reading it field by field:

• $2b$ — the bcrypt variant (bcryptjs emits $2b$; verification also accepts $2a$, $2x$, $2y$).
• 12 — the cost factor, meaning 2^12 key-expansion rounds.
• the next 22 characters — the random salt.
• the final 31 characters — the derived hash.

Switch to Verify, drop the hash above into the existing-hash field, type hunter2, and the verdict is match. Type Hunter2 instead and it is no match — bcrypt is case-sensitive, and a single wrong character flips the result. The elapsed-time figure shown alongside is the real cost of one verification at cost 12 on your machine.

FAQ#

What cost should I choose?#

12 is a solid default for new systems today — it takes roughly a few hundred milliseconds on typical hardware, which is painless for a real login but painful for bulk guessing. Raise it to 13 or 14 for high-value targets where a slightly slower login is acceptable. The key rule is to re-tune upward over the years as hardware improves, because bcrypt’s cost scales exponentially: each increment of 1 roughly doubles the time.

Why does hashing the same password twice give different results?#

Because bcrypt generates a fresh random salt each time and embeds it in the output. The two hashes look nothing alike, yet both verify against the same password. That is the whole point of salting — it stops an attacker from recognising repeated passwords or reusing a precomputed table.

Can I verify a hash generated somewhere else?#

Yes, as long as it is a well-formed bcrypt string ($2a$, $2b$, $2x$, or $2y$). Paste it into the existing-hash field in verify mode; the tool reads the cost and salt from the hash itself. Hashes exported from Node’s bcrypt, PHP’s password_hash, or Python’s passlib all work here.

Is bcrypt better than SHA-256 for passwords?#

For storing login passwords, yes — emphatically. SHA-256 is fast, which is exactly the wrong property for a stored password hash: an attacker with the hash can try billions of guesses per second on a GPU. bcrypt is deliberately slow and salted, which is what password storage demands. Use SHA-256 for integrity and signatures; use bcrypt (or its cousins Argon2/scrypt) for human passwords.