Skip to content
bcryptdog

Your password never reaches a server.

Most online hash generators send what you type to a server. This one has no server to send it to. The page is a handful of static files, and the algorithm runs inside the dark panel below.

Everything below this line runs locally

0/72 bytes 4,096 iterations 0 network requests

Check a password against a hash

The cost and salt live inside the hash string, so verification needs nothing except the hash itself and the password you want to test. This is the same comparison your login endpoint runs.

Verification also runs locally

There is a full page for verification if that is all you came for, and a note on why decryption is not a thing bcrypt can do.

bcrypt only reads the first 72 bytes

Nothing after that reaches the hash, so a longer password buys you nothing. Most libraries drop the extra bytes without a word; Go and Python 5.0 and later refuse the password instead. The grid below fills up as you type in the box above.

0 of 72 bytes used

It catches people out with passphrases and with pre-hashed input. The write up on the 72 byte limit covers where it actually bites and how to work around it.

Why bcrypt is slow

bcrypt is built to be expensive to compute, which is what wastes an attacker's time. You pick how expensive it should be, and the hash gets generated right here.

Niels Provos and David Mazières designed bcrypt in 1999. It is based on the Blowfish cipher and it is slow by design, which is exactly what makes brute forcing it expensive.

The cost factor decides how many iterations the algorithm runs. Each step up doubles the work, and an attacker with a GPU cluster pays that same multiplier.

Every hash gets its own random salt, so two identical passwords produce different output. Version, cost and salt all live inside the hash string, so you only need to store that one value to verify a login later.

Every step doubles the work

Pick how expensive a single password guess should be. The bars are drawn to scale: cost 15 is 128 times the work of cost 8.

Cost is set to 12. Nothing hashed yet.

Which cost factor to pick goes through how to measure this on your own hardware and how to raise it on a database that is already live.

Iterations per cost factor

Newer defaults have moved to 12, including Laravel, PHP from 8.4 and bcrypt-ruby. Go and Spring Security still ship 10, which is also the floor OWASP gives. Anything below 8 is too cheap to be worth it, and above 15 your own login times start to suffer.

cost 4
16 iterations
cost 8
256 iterations
cost 10
1,024 iterations
cost 12
4,096 iterations
cost 14
16,384 iterations
cost 16
65,536 iterations

Everything sits in one string

A bcrypt hash is four fields concatenated together. Store that one value and you can verify a login later, without a separate salt column or any settings to keep track of.

Sample hash

$2a

Version

The bcrypt variant that produced this

$12

Cost

Doublings of work per guess

$R9h/cIPz0gi.URNNX3kh2O

Salt

22 random characters, new every time

PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW

Digest

31 characters of output

The version field is the one that trips people up between languages. What $2a, $2b and $2y mean explains where each letter came from.

Hashing the same password twice gives two different hashes

Every hash gets its own random salt, so two users who pick the same password end up with completely different rows in your database. Cracking one of them does not help an attacker with the other.

How it works

What actually runs on this page

Runs in your browser
The hashing happens on this page, in your browser. Your password stays in the tab you typed it into.
No backend
The site is a handful of static files. There is no API behind it and no database to write anything to.

Where you'll find bcrypt

Each of these writes a slightly different prefix and defaults to a different cost. The pages below set the tool up the way that stack expects and show the matching code.

Laravel
The default password hasher, set to 12 rounds out of the box.
Ruby on Rails
has_secure_password uses the bcrypt-ruby gem.
Node.js
The bcrypt package is the common choice on npm.
Django
Includes BCryptSHA256PasswordHasher as a supported backend.
Spring Boot
BCryptPasswordEncoder is the default in Spring Security.
Go
Available in the extended library as golang.org/x/crypto/bcrypt.

Questions people ask

Is it safe to put a real password into this page?
The hashing runs in your browser and the page makes no network request when you press the button, so nothing is transmitted. That said, several other online generators do send the password to their server, so the habit of not pasting live production passwords into web pages is a good one to keep.
How many rounds should I use?
Cost 12 suits most web applications and lands around 200 milliseconds on current hardware. Aim for a quarter to half a second on the machine that will actually run it, and raise the number until you get there.
Can a bcrypt hash be decrypted back to the password?
No. Bcrypt is a one way function, so there is nothing to reverse. Tools that advertise bcrypt decryption are either guessing common passwords or looking the hash up in a table of hashes they made earlier.
Why does the same password produce a different hash every time?
Each hash gets its own random 22 character salt, which is stored inside the hash string. Two accounts with the same password end up with different rows, so cracking one gives an attacker nothing for the other.
What is the difference between $2a, $2b and $2y?
They mark which implementation quirk the hash was produced under. For any password under 72 bytes the output is identical, and most libraries verify all three. PHP writes $2y, Node and Python write $2b, Java and Go write $2a. PHP is the one place where the letter still decides the outcome: password_verify accepts all three, but password_get_info reports bcrypt only for $2y, and that is what Laravel Hash::check consults first, so a $2b hash comes back as "This password does not use the Bcrypt algorithm" even though the digest is right. That is why the generator above starts on $2y: it is the one prefix every common library accepts, so it is the safe choice when you are not sure where the hash is going.
Is bcrypt still worth using in 2026?
For a new project, no: use Argon2id. The current OWASP guidance puts Argon2id first and scrypt second, and says bcrypt should only be used for password storage in legacy systems where neither is available. On a database that already runs bcrypt at a sensible cost factor the practical answer is softer, because raising the cost factor is an afternoon and a migration is not, and the hash function is rarely what loses accounts. Treat that as an engineering trade-off rather than the standard, and note that a compliance framework or a security questionnaire may not accept it.

Other tools here