bcrypt Password Hasher
Generate a salted, adaptive bcrypt hash for any password, locally in your browser.
Your data is processed entirely in your browser and is never uploaded.
Tool workspace
Options
Higher is slower to compute and harder to brute-force. 10 is the common default.
Generate a bcrypt hash in three steps
Enter a password
Type or paste the secret you want to hash: a password, a recovery code, an API secret.
Pick the cost factor
Choose how expensive the hash should be. Higher cost means slower, safer hashing; 10 is the recommended default.
Generate & store
Click Generate, then copy the hash. Every run draws a fresh random salt, so the same password never hashes twice alike.
A salted, adaptive password hash, computed locally
bcrypt is a password-hashing function built to be deliberately slow and to resist guessing. Instead of a fixed-size checksum, it runs the input through many rounds of key stretching (2^cost with the default cost of 10 giving 1,024 rounds), mixing in a fresh random salt every time. The result is a 60-character string that embeds the algorithm, cost, salt, and hash, like $2b$10$Kixh0btLXwHixE3GB4m3dOGnUjZQ5L6Za3nHfqHXzJLy9gL8Ywym. Because the salt is unique per hash, the same password never produces the same hash twice, which stops precomputed tables and lets you spot nothing about two users sharing a password. Hashing runs entirely in your browser, in a background worker, so nothing is uploaded and the UI stays responsive even at high cost factors.
Things to know
Empty input hashes nothing
With nothing to hash the tool reports empty output. Enter a password first, then click Generate. The result always comes back as a 60-char bcrypt string.
The same input never hashes twice alike
Every Generate call draws a fresh random salt, so rerunning the same password gives a different hash. Both are valid. Compare by re-hashing, not by string equality.
Higher cost, safer hashes
The cost factor controls the workload (2^cost rounds). Higher values take longer to compute. A fraction of a second for you, months of GPU time for an attacker. 10 is the common default; raise it when hardware gets faster.
Not a checksum
bcrypt is for password storage, not integrity checking. For content checksums and fingerprints use a fast hash like SHA-256 or SHA-512.
Try these
correct horse battery staple
Hash a typical password and see the 60-char bcrypt string with its embedded salt.
my-secret-api-token
Longer secrets hash just the same. The output length never changes.
my-very-secret-password
Set the cost factor to 12 and re-generate. Note the $2b$12$ prefix and the pause.
pair this withFast checksum instead → SHA-256 Hash Generator·Stronger checksum → SHA-512 Hash Generator·Encode the hash → Base64 Encode / Decode
Go deeper
Quick answers
Is my password uploaded?
No. Hashing runs entirely in your browser, in a background worker. Nothing you enter leaves your machine.
Why does the same password give a different hash?
bcrypt embeds a random salt in every hash, so identical passwords produce different hashes. That's intentional: it stops attackers from precomputing tables or spotting duplicate passwords in a database.
What does the cost factor do?
The cost factor controls how many rounds of key stretching bcrypt runs: 2^cost. Higher values take longer to compute but make brute-forcing far more expensive. 10 is the common default; use 11–12 for new systems. See the SHA-256 vs bcrypt comparison.
Is bcrypt right for checking a file checksum?
No. bcrypt is for password storage. For checksums, fingerprints, and content verification use a fast hash like SHA-256 or SHA-512 instead.
How long does bcrypt hashing take?
With a normal cost factor of 10 to 12, hashing takes from tens to a few hundred milliseconds on a typical CPU. That delay is intentional and is what makes brute force expensive.
What does $2a$10$ at the start of a hash mean?
The version marker and the cost factor. $2a$ is the bcrypt variant, and 10 means 2^10, or 1,024 rounds, of key stretching were used.
Should I use bcrypt or argon2?
Both are secure. Argon2 is newer and memory-hard; bcrypt is more widely supported. Either one beats a fast hash for passwords.
What is the bcrypt 72-byte limit?
bcrypt only considers the first 72 bytes of input, so longer passwords are truncated. Applications enforce a length limit up front or pre-hash long inputs, which carries its own tradeoffs.