Type a password into this bcrypt generator, pick a cost factor, and you get a 60-character salted hash that is safe to store in a user table. Bcrypt hashes are built for password hashing, a one-way job where a deliberately slow hashing function protects every account if your database ever leaks, so the sections below explain what the output means and how to choose its settings.
Using the Online Bcrypt Generator and Validator
The tool has two halves. The generate hash half takes your plain text and a cost factor, then returns a fresh hash string; collect several password hashes this way and you can build a whole test table in minutes. The verify hash half takes a hash and a candidate password, then tells you whether the two match, so you can validate a stored value without writing any code. Both halves run in your browser, so the text you type is never uploaded to a server.
- Enter the password you want to hash.
- Choose the rounds (the cost factor). A value of 12 is a sensible default for production.
- Press the button and copy the 60-character result.
- To check a hash, paste it with the original password and compare them.
Run the same password twice and you will get two different hashes. That is expected, because every run draws a new random salt. Only the verifier can tell you that both belong to the same password.
How a Bcrypt Hash Generator Builds a Hash String
Bcrypt is a password hashing function, and a cryptographic hash function in the broader sense, designed by Niels Provos and David Mazieres, based on the Blowfish cipher, and presented at USENIX in 1999. Unlike a plain checksum, it is computationally intensive on purpose. Every bcrypt hash generator, this one included, produces a hash string with the same layout, which you can read left to right:
| Part | Example | Meaning |
|---|---|---|
| Version prefix | $2b$ | The bcrypt algorithm revision |
| Cost | 12 | Work factor, as a power of two |
| Salt | XTZfwWD2kX.nnHHwbcGCwu | 22 characters of random salt |
| Digest | nf3M02bioII2fa4YJZo1i8H/uvr7YEy | 31 characters of output from the cipher |
Why the salt is stored inside the hash
Because the salt is stored in the output itself, you never need a separate salt column. A verifier reads the salt back out of the hash, repeats the computation, and compares. The random salt also defeats a precomputed rainbow table, since one table of guesses cannot be reused against many accounts.
Choosing the Cost Factor for Your Bcrypt Hasher
The cost factor, also called the work factor or the number of rounds, controls how many iterations the algorithm runs. Each step up doubles the work:
$$\text{work} = 2^{\text{cost}}$$
A cost of 10 therefore means \(2^{10} = 1{,}024\) iterations, and a cost of 12 means \(2^{12} = 4{,}096\). Timings from a laptop-class CPU show how quickly that adds up for one password:
| Cost | Passes | Time per hash |
|---|---|---|
| 8 | 256 | 0.016 s |
| 10 | 1,024 | 0.055 s |
| 12 | 4,096 | 0.216 s |
| 14 | 16,384 | 0.949 s |
Rounds, speed and your hardware
Pick the highest cost that keeps a login responsive on your own hardware, commonly a fifth to a quarter of a second per check. A cost above 12 can take several seconds in a browser tab, so test larger values on your server instead. As hardware gets faster you raise the number and old hashes keep working.
Password Hashing with Bcrypt vs Fast Digests and Memory-Hard Options
Fast digests such as MD5 and SHA-256 are excellent for file checksums and poor for passwords, because a single GPU can compute billions of them per second. Bcrypt, scrypt and Argon2 are slow by design, which makes brute-force attacks far more expensive. The Password Hashing Competition, an open contest run by cryptography experts, ended in 2015 with Argon2 as its winner, and bcrypt remains widely deployed and well understood.
- MD5 and SHA-256: fast, so unsuitable on their own for storing passwords.
- Bcrypt: tunable cost, built-in random salt, mature libraries in every language.
- scrypt and Argon2: add memory hardness, which raises the price of GPU cracking further.
Bcrypt is the hashing algorithm many frameworks pick first, though it does have a limit: it only reads the first 72 bytes of the input, so very long passphrases are cut off.
Worked Example: Running a Password Through the Bcrypt Hash Verifier
Take the plain text maple-Harbor-4821 and a cost of 12. The generator returns the hash below, which spends 4,096 passes and about 0.216 seconds of CPU time:
$2b$12$XTZfwWD2kX.nnHHwbcGCwunf3M02bioII2fa4YJZo1i8H/uvr7YEy
Paste that hash into the verifier with maple-Harbor-4821 and it reports a match. Change one letter, as in maple-harbor-4821, and it reports no match, because bcrypt is case-sensitive and a single changed character produces a completely different digest. Your own run will show a different hash for the same text, and that is fine, since the salt is new each time.
Bcrypt Encoder and Bcrypt Encrypt: Clearing Up the Terminology
Many people search for a bcrypt encoder or type bcrypt encrypt, but bcrypt is not encryption. Encrypted data can be decrypted with a key; a bcrypt hash cannot be reversed at all. A one-way function turns plain text into a fixed size string, and the only way to test a guess is to hash it again and compare. That is exactly why it suits authentication: your server never needs to know the original password.
Testing Rounds on a Staging Server with a Bcrypt Hasher
A backend developer is moving a login route off salted SHA-256 and has a latency budget of 300 ms per sign-in on a staging box. The question is which cost to set, so she runs the same test password through the generator at four cost settings, quill-Fennel-7305, and writes down the timings.
| Cost | Passes | Measured time | Against the 300 ms budget |
|---|---|---|---|
| 10 | 1,024 | 0.057 s | Fits, but the weakest option |
| 11 | 2,048 | 0.113 s | Fits with room to spare |
| 12 | 4,096 | 0.242 s | Fits, 58 ms under budget |
| 13 | 8,192 | 0.461 s | Fails, 161 ms over budget |
Cost 13 doubles the 0.242 seconds she saw at cost 12 and lands at 0.461 seconds, which breaks the budget before any network time is added. Cost 10 is the lowest value the OWASP Password Storage Cheat Sheet accepts for bcrypt, so she treats it as the floor and not the target. That leaves 12 as the highest setting that still fits.
She pastes the generated hash for cost 12, $2b$12$GHPJpxD6l9M9w./ohhrYjeJ./h/36ts5ClWjHULQQhnhlF66D36T., into the verifier with the same password and sees a match, which confirms the $2b$ prefix is one her library understands. The comparison also tells her the result of this bcrypt hashing exercise: cost 12 stays inside the budget with 58 ms to spare for the database lookup.
Her next step is concrete. She sets the cost to 12, the value the generator's timing test settled on, then adds a rule that rehashes any older SHA-256 entry with bcrypt at cost 12 the next time that user signs in, so the table upgrades itself without a forced reset.
Bcrypt Password Generator Tips for Developers
The generator hashes exactly what you type, so a weak input gives a weak hash. A strong password mixes length with unpredictability, and a long random passphrase beats a short string of symbols. If you need a secure password to hash, create it with a random generator first and then hash it here.
Bcrypt hashes for test fixtures and seed data
A web developer often needs a handful of valid hashes for seed data. Generate them once, paste them into your fixtures for cross-browser testing and login suites, and your login tests behave like production. High rounds also make a slow test case that can expose denial of service and resource exhaustion problems in a login route.
Bcrypt Hashing in PHP, Java and NodeJs
Hashing in your own code should use a trusted library rather than a web page. PHP ships password_hash, Java and NodeJs have well-maintained packages, and each produces a hash string in the same $2b$ format, so a hash made here verifies there. The libraries are open source, and several browser tools, including this one, build on the bcryptjs package, also written bcrypt.js. Treat this page as a place to test and learn, and do your production hashing server-side.
Is It Safe to Use an Online Bcrypt Tool in Your Browser?
Because everything runs client-side, the password stays on your device, and you can confirm that in your browser's network panel. Still, never paste a real production password into any website. Use sample credentials, keep the database of real hashes on your server, and rely on trusted libraries for anything user-facing. Treat any bcrypt hashing tool as a learning aid: real security comes from your own server code, strong cost settings and careful handling of every credential. Store only the hash, never the plain text, and raise the cost as your servers get faster. A leaked hash gives an attacker nothing to read, only an expensive guessing game, and the cryptographic design of bcrypt is what keeps that game slow for attackers. Programmers can run both halves of this tool, generate and verify, to see that behaviour for themselves.
Frequently Asked Questions
- What is bcrypt?
- Bcrypt is a password hashing function designed to be computationally intensive and resistant to brute-force attacks. It incorporates a salt to protect against rainbow table attacks and a cost factor that lets you increase the hashing work over time as hardware gets faster. It is widely used for securely storing passwords in databases.
- How many rounds (cost factor) should I use?
- A cost factor of 12 is the recommended minimum for production environments as of current best practices. Higher values increase security but also increase processing time exponentially — each increment doubles the computation time. For most modern servers, 12 to 14 provides a good balance of security and performance.
- Is this bcrypt generator secure to use?
- Yes. All hashing and verification processing happens entirely within your browser using the bcryptjs JavaScript library. No data is transmitted to any server or stored anywhere. Your passwords and hashes never leave your device.
- Can I use this tool in production?
- This tool is primarily intended for testing, learning, and development purposes. For production applications, you should implement bcrypt hashing server-side using a trusted library in your programming language (e.g., bcrypt for Node.js, bcrypt for PHP, or Spring Security for Java) to ensure hashes are generated and compared securely within your own environment.
- What is password hashing and why is it important?
- Password hashing is a one-way cryptographic process that converts a plain text password into a fixed-length string called a hash. Because it is a one-way function, the original password cannot be derived from the hash. This means even if a database is breached, attackers cannot easily recover the actual passwords.
- Why does bcrypt always produce a different hash for the same input?
- Bcrypt automatically generates a unique random salt each time it hashes a string. This salt is embedded into the resulting hash string. Even if two users have the same password, their bcrypt hashes will be different, making precomputed rainbow table attacks ineffective.
- How do I verify a bcrypt hash?
- To verify a bcrypt hash, use the Verify Hash section: paste your existing bcrypt hash into the 'Bcrypt Hash' field and enter the original plain text password. The tool will compare them and tell you whether the text matches the hash. Bcrypt extracts the embedded salt from the hash to perform the comparison correctly.
- What does the bcrypt hash string format look like?
- A bcrypt hash looks like:
$2a$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy. The prefix '$2a$' indicates the bcrypt algorithm version, '12' is the cost factor, the next 22 characters are the base64-encoded salt, and the remaining characters are the hashed password. The total length is always 60 characters.