Bcrypt Generator & Checker

Share:

Hash passwords with bcrypt and verify $2a$, $2b$ and $2y$ hashes in your browser, with a warning when a password passes the 72-byte limit.

RT-CW3-004 · Crypto & Web3
Your browser is too old for this tool’s interactive features. Please update to Safari 13.1, Chrome or Edge 80, Firefox 74 or newer.

Bcrypt Generator Tool

Privacy: All bcrypt hashing happens inside your browser via self-hosted bcryptjs (no third-party CDN). Your password never leaves this page. For production password storage, run bcrypt server-side — this tool is for testing, debugging, and learning.
10 ~100ms
Advertisement
After results · AD-W1 Responsive · Post-tool — peak engagement

How to use the bcrypt generator

Hash mode

Enter a password and pick the cost factor (4 to 14). Each step up doubles the work. OWASP recommends bcrypt only for legacy systems, with a cost of at least 10; the page shows how long your browser took.

Read the hash

The output is a 60-character string such as $2a$10$…: the version, the cost, a 22-character salt and the 31-character hash, in bcrypt's own radix-64 alphabet. PHP's password_verify(), Node's bcrypt libraries and others read it directly.

Verify mode

Paste a hash and a candidate password. The cost and salt are read from the hash itself, the password is hashed again with them, and the tool tells you whether it matches. Hashes starting $2a$, $2b$ or $2y$ (the PHP prefix) are accepted.

Note the same-password-different-hash rule

bcrypt adds a random 128-bit salt to every hash, so hashing the same password twice gives two different strings, and both verify. Only the first 72 bytes of a password count; the tool warns you if yours is longer.

Advertisement
After how-to · AD-W2 Responsive

bcrypt — the password-storage standard that has aged well

bcrypt is a password-hashing function published by Niels Provos and David Mazières at the 1999 USENIX conference (Provos and Mazières, USENIX 1999). It was designed for OpenBSD to make each password guess deliberately expensive, and to let that expense rise as hardware gets faster, through a single cost parameter.

How it works

bcrypt is built on the Blowfish cipher. Its "EksBlowfish" key schedule mixes in a 128-bit salt and the password, then repeats the expensive part 2cost times, so cost 10 means 1,024 rounds and each step up doubles the work. The resulting state encrypts the 192-bit text "OrpheanBeholderScryDoubt" 64 times, and the output is stored with the version, cost and salt in one string. Verifying a password repeats exactly the same steps with the stored cost and salt.

"For legacy systems using bcrypt, use a work factor of 10 or more and with a password limit of 72 bytes." OWASP Password Storage Cheat Sheet

The 72-byte limit

The original paper describes passwords of up to 56 bytes; common implementations, including the bcryptjs library this page uses, take up to 72 bytes and ignore the rest. Checked here: a 77-character password verifies against the hash of its first 72 characters. OWASP recommends enforcing a maximum of 72 bytes, or pre-hashing longer passwords with care. Note that the limit is in bytes, so a password in Chinese or with emoji reaches it in fewer characters.

Prefixes

You will see $2a$, $2b$ and $2y$ at the start of bcrypt hashes. They mark versions of the algorithm and its implementations; PHP's password_hash(), for example, "will produce a standard crypt() compatible hash using the $2y$ identifier", according to the PHP manual. Since PHP 8.4 its default bcrypt cost is 12, up from 10. This page produces $2a$ hashes and verifies all three prefixes.

bcrypt, Argon2 and PBKDF2

For new systems OWASP recommends Argon2id, the winner of the 2015 Password Hashing Competition, with at least 19 MiB of memory, 2 iterations and 1 degree of parallelism; scrypt if Argon2id is unavailable; bcrypt for legacy systems; and PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations where FIPS-140 compliance is required. Whatever you use, hash passwords on the server: hashing in the browser, as this teaching tool does, exposes the password to anything else running on the page.

How bcrypt works, its 72-byte limit and what OWASP recommends now

01

bcrypt was published by Niels Provos and David Mazières at the 1999 USENIX Annual Technical Conference.

02

Each password gets a random 128-bit salt, so the same password never hashes to the same string twice.

03

The expensive step runs 2cost times: cost 10 is 1,024 rounds, and each step up doubles the work.

04

The final state encrypts the 192-bit text "OrpheanBeholderScryDoubt" 64 times.

05

Common implementations use only the first 72 bytes of a password; the paper itself describes 56.

06

OWASP recommends bcrypt only for legacy systems, at a cost of 10 or more.

07

For new systems OWASP recommends Argon2id, winner of the 2015 Password Hashing Competition.

08

Where FIPS-140 compliance is required, OWASP points to PBKDF2-HMAC-SHA-256 with at least 600,000 iterations.

09

PHP's password_hash() writes the $2y$ prefix; its default cost rose from 10 to 12 in PHP 8.4.

10

A bcrypt hash is 60 characters: version, cost, 22-character salt and 31-character hash.

Frequently asked questions

]; @endphp
Every hash includes a random 128-bit salt, stored inside the hash string. Two hashes of the same password therefore differ, which defeats precomputed tables and hides users who share a password. Verification works because it reads the salt back from the stored hash.
OWASP recommends at least 10 for bcrypt, and as high as your server can afford while keeping logins quick. PHP raised its default to 12 in version 8.4. Measure on your own server: this page shows how long your browser took, which is only a rough guide.
It is a 72-byte limit in common implementations: anything after the 72nd byte is ignored, so two passwords that share their first 72 bytes produce the same hash. OWASP recommends enforcing a 72-byte maximum. The limit is in bytes, so non-Latin characters and emoji reach it sooner. This page warns you when a password is longer.
OWASP recommends Argon2id for new systems and treats bcrypt as acceptable for legacy ones at a cost of 10 or more. A common way to migrate is to re-hash each password with the new algorithm the next time its user logs in successfully.
No. Passwords should be hashed on your server. Hashing in a browser means the password sits in the page, where browser extensions and scripts can reach it. Use this tool to learn, test and check hashes with throwaway passwords.
They are prefixes that mark versions of bcrypt and its implementations. PHP's password_hash() writes $2y$; bcryptjs, used here, writes $2a$. This page verifies all three; until 1 October 2026 it rejected $2y$, so PHP and Laravel hashes could not be checked.
OWASP's guidance is that where FIPS-140 compliance is required you should use PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations, rather than bcrypt.
The stored hash contains the cost and the salt. Verification hashes the candidate password again with that cost and salt and compares the result with the stored hash. The same password, cost and salt always give the same output.
A pepper is a secret added to passwords before hashing and kept outside the database, for example in a hardware security module or the application's secret store. OWASP describes it as extra defence in depth: an attacker who steals only the database still lacks the pepper.
bcryptjs 2.4.3, a pure-JavaScript implementation, served from this site. Nothing you type is sent anywhere.

Method & sources

How it computes

Hashes with self-hosted bcryptjs 2.4.3 (genSaltSync(cost), hashSync, compareSync) at cost 4-14, and verifies 60-character $2a$, $2b$ and $2y$ hashes. Warns when the password exceeds 72 UTF-8 bytes, the limit OWASP gives and this build enforces (a 77-byte password verifies against the hash of its first 72).

What this tool implements

  • The verifier rejected $2y$ hashes, PHP's prefix (password_hash), although bcryptjs verifies them; every PHP and Laravel hash failed here. Longer-than-72-byte passwords were hashed with no warning. Both fixed; tested against the vendored library.
  • OWASP: Argon2id for new systems (19 MiB, t=2, p=1), bcrypt for legacy at work factor 10+, PBKDF2-HMAC-SHA-256 at 600,000+ for FIPS. The page had Argon2id at '64MB, t=3'. Construction per Provos and Mazières (128-bit salt, 2^cost rounds, 'OrpheanBeholderScryDoubt' 64 times); PHP 8.4 raised its default cost to 12.
  • Removed as unsourced: a quoted MAS TRM / BNM RMiT requirement, the 2012 LinkedIn breach figures, GPU hash rates, a '2014 OpenBSD bug' account of $2b$, 'every WordPress install', and Django/Rails pre-hashing claims.

Sources

Advertisement
Pre-footer · AD-W3 728 × 90