Free Online Password Hash Generator for bcrypt and PBKDF2
Hash a password with bcrypt or with PBKDF2, with the cost, the salt and the iteration count all in your hands, and check a password against a hash you already have. The time each hash takes is measured and shown, because a work factor is only meaningful as a number of milliseconds on real hardware.
Free Forever Nothing Uploaded bcrypt And PBKDF2 Cost Timed
Share this tool
Advertisement Slot (Top Banner)Google AdSense Unit • Responsive Banner
Password Hash Generator Everything happens in this tab. Nothing you paste is sent anywhere.
The password
The hash
To store
Salt
Digest, hex
Job
Algorithm
Cost
IterationsDjango uses 600,000 with SHA-256 at the time of writing.
Salt
Buy Us A Coffee
Enjoying WizTools123? Help keep our server infrastructure
100% free and open for everyone.
Argon2id is the current best answer for storing a password, and it is not on this page. The
first reason is practical: running it in a browser needs a WebAssembly bundle, and the whole
point of Argon2 is to use a lot of memory, which on a phone means a wait of a second or two
for one hash. That would make this page feel broken while doing exactly what it was asked.
The second reason matters more. A password hash should be computed where the password arrives,
which is your server, with parameters tuned to that server hardware. A hash produced in a
browser tab is useful for a test fixture, for a seed file, or for checking that a stored value
matches, and that is what bcrypt and PBKDF2 are offered for here. If you are choosing an
algorithm for a real system, choose Argon2id in your server library, give it at least 19 MB of
memory and two passes, and never let a browser do that job.
If you have an Argon2 hash and want to know what it says, the hash identifier on this
site reads its parameters. It will show the memory, the passes and the lanes out of the
string, which is usually what you need when you are auditing someone settings rather than
producing a hash.
How to Hash a Password
A few steps, and nothing is uploaded.
1
Type the passwordIt is hashed in the page. Nothing is uploaded, and nothing is kept once the tab is closed.
2
Choose the algorithm and the costbcrypt with a cost between 4 and 15, or PBKDF2 with an iteration count of your own. The cost is the whole of the protection, so it is the setting worth thinking about.
3
Read the time it tookA work factor is only meaningful as a duration. The page times every hash and says whether that duration is in the right range for a login.
4
Or check a hash you already haveSwitch to checking, paste the stored hash, and the page tells you whether the password matches it. The salt and cost come out of the hash itself.
What to Know About Password Hashes
Including why a fast hash is the wrong tool and Argon2 is not here.
A fast hash is the wrong tool for a password, however many times you apply it. SHA-256 is designed to be fast, which is exactly what you do not want: a graphics card will try billions of candidates a second against it. bcrypt and PBKDF2 are built to be slow and to stay slow, with a cost you raise as hardware improves. If you find a password column holding bare SHA-256 or MD5, that is the finding, salt or no salt.
bcrypt ignores everything past 72 bytes of the password. That is a property of the algorithm, not of this page. A 100 character passphrase is silently truncated, so two passwords that share their first 72 bytes verify against the same hash. It matters mostly for machine generated secrets; if that is your situation, hash the password with SHA-256 first and bcrypt the result, or use Argon2 instead, which has no such limit.
The salt is not a secret and does not need to be hidden. Its job is to make sure two people with the same password get different hashes, so a precomputed table cannot cover both. bcrypt and the Django style PBKDF2 format both store the salt inside the hash string, which is why a single column is enough and why you never have to manage a second one. A random salt per password is the whole requirement.
This page cannot tell you that a cost is high enough for your server. It times the hash on the machine you are using now, which is a reasonable guide and not a measurement of your production hardware. The usual target is that one hash takes somewhere between 100 and 250 milliseconds on the server that will run it, which you have to measure there. An attacker gains from better hardware, not from better arithmetic.
Key Features & Capabilities
What this tool does, and what it deliberately does not.
bcrypt and PBKDF2bcrypt from a vendored library, PBKDF2 from the browser own Web Crypto.
The cost timedEvery hash is timed, with a plain judgement about whether that duration is sensible.
Checks an existing hashPaste a bcrypt or Django style PBKDF2 string and see whether a password matches it.
A real random saltFrom the browser cryptographic random source, with the option to pin one for a test.
The parts shownThe salt and the raw digest separately, as well as the single string you store.
Honest about Argon2Not offered, with the reason stated, rather than quietly left out.
About Password Hashing
Storing a password means storing something that proves a later guess was right without being the password itself. A hash does that, but an ordinary hash does it badly: SHA-256 was designed to be fast, and fast is precisely wrong here, because the attacker with your database runs the same function billions of times a second on a graphics card. The answer is a function built to be slow and to have its slowness turned up over the years as hardware gets better, which is what bcrypt, PBKDF2, scrypt and Argon2 all are.
This page offers bcrypt and PBKDF2 because both can run honestly in a browser. bcrypt comes from a vendored library, the long standing JavaScript implementation, and PBKDF2 comes from the browser own Web Crypto, the same code it uses for TLS. Both are given with the cost, the salt and the iteration count in your hands rather than hidden, because those parameters are the entire difference between a hash that protects a leaked database and one that does not.
The feature worth the most here is the timer. A cost of 10 or 600,000 iterations is a number with no meaning until it becomes a duration, and the duration depends on the machine. Seeing that one hash took 60 milliseconds here, and that the usual target on a server is 100 to 250, turns an abstract setting into a decision you can actually make. The same timer is why raising bcrypt cost by one and watching the time double teaches the idea faster than any explanation.
What the page does not do is pretend to be the right place for production work. It will not produce an Argon2 hash, for reasons set out above, and a hash made in a browser tab belongs in a test fixture or a seed file rather than in a live user table. Checking an existing hash is the exception: that is a genuinely useful thing to do here, because the salt and the cost travel inside the string and nothing else is needed.
Frequently Asked Questions
Cost, salts, verifying, and the 72 byte limit.
Whatever makes one hash take between 100 and 250 milliseconds on the server that will run it. That is usually 10 to 12 today. The page times each hash so you can see the effect, remembering that your server is probably slower than your laptop and that each step up doubles the work.
Because each one uses a new random salt, which is stored inside the hash string. That is the point: it stops a precomputed table covering everyone who chose the same password. Verification still works, because the salt is read back out of the stored string.
For a test fixture or a seed file, yes, and it is a good use of the tool. For a real user account, hash the password where it arrives, on your server, with parameters tuned for that machine. A browser tab is the wrong place for that step even though the output is a valid hash.
It ignores anything past 72 bytes. That is the algorithm, not this page. It is rarely an issue for human passwords and does matter for long machine generated secrets, where pre-hashing with SHA-256 or using Argon2 is the usual answer.
No. bcrypt runs from a JavaScript file served with the page, and PBKDF2 runs in the browser own cryptography. No request is made, which you can confirm in the Network tab or by turning the network off after the page has loaded.
Every Other Security Tool
10 more tools in this set. All free, all in your browser.
