Skip to content
AZ Tools

Bcrypt Hash & Verify

Generate bcrypt hashes with adjustable cost factor, or verify an existing hash against a password — runs entirely in your browser.

Output

—

How to use

  1. Hash mode: type the password, choose cost (10 is the modern default), click generate.
  2. Verify mode: paste a hash starting with $2a$, $2b$, or $2y$, type the candidate password, click verify.
  3. Copy the hash.

About this tool

Show

Bcrypt is the default choice for storing passwords: deliberately slow, and with the salt carried inside the hash string itself. This tool generates hashes at a cost factor from 4 to 14 — each step doubles the work, so 12 takes roughly 256 times as long as 4 — and verifies an existing hash against a candidate password. Because a fresh random salt is used every time, hashing the same password twice gives two different strings, and both still verify; that is the design working, not a bug. Hashes are produced with the $2b$ prefix, and verification also accepts the older $2a$ and $2y$ forms. Note that bcrypt only reads the first 72 bytes of a password, so anything past that does not affect the result. Everything runs in your browser via bcryptjs; the password never leaves the page.

Frequently asked questions

Which cost factor should I use?

10 is the modern default (~100ms on a server CPU). Use 12 for high-value secrets; 14 for offline-only secrets. Below 8 is too fast in 2026.

Why is cost 14 slow in my browser?

Each cost increment doubles the work. Cost 14 takes ~1–4s on a typical laptop — that's the point.

What's the difference between $2a$, $2b$, $2y$?

Format prefixes from different bcrypt implementations. All modern libraries verify all three interchangeably.

Is bcrypt still recommended in 2026?

Yes, with cost ≥10. Argon2id is preferred for new projects but bcrypt remains widely supported and safe at appropriate cost.

The same password gives a different hash every time. Is something wrong?

No — that is the design working. A fresh random salt goes into each hash, so two hashes of one password never match, and both still verify because the salt is stored inside the string. Identical hashes would mean no salt, which is what makes rainbow tables possible.

Does a very long passphrase make the hash stronger?

Only up to 72 bytes. Bcrypt reads no further, so everything past that point is ignored and two passphrases sharing their first 72 bytes verify against the same hash. Note that is bytes, not characters — accented letters and emoji reach the limit sooner.

Guides on this topic

Related tools