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 black box 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
Anything after that gets dropped before hashing starts, so a longer password buys you nothing. 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
Most frameworks default to 12 these days. 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
Version
The bcrypt variant that produced this
Cost
Doublings of work per guess
Salt
22 random characters, new every time
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?
- Yes. Argon2id is the current first recommendation for new projects, but bcrypt at a sensible cost factor is still a sound choice and there is no urgency to migrate an existing database away from it.