Password Hash Generator
Free password hash generator — produce Argon2id, Argon2i, Argon2d, bcrypt, scrypt or PBKDF2 hashes as PHC strings, with tunable cost parameters and timing, plus a verifier. Runs locally in WebAssembly; nothing is uploaded.
Verify a hash
Paste a PHC string and the password it should match. The parameters are read from the string itself.
Runs entirely in your browser — nothing you enter is uploaded or stored.
Hashing passwords for storage
A password hash is not a hash in the ordinary sense. An ordinary hash wants to be fast; a password hash wants to be slow, and increasingly wants to be expensive in memory as well, because that is what an attacker with a rack of GPUs cannot cheaply parallelise.
The PHC string
Every scheme here outputs a single self-describing string —$argon2id$v=19$m=19456,t=2,p=1$salt$digest — carrying the algorithm, its parameters, the salt and the digest together. Store exactly that. You never need a separate salt column, and when you raise the cost next year, old hashes keep verifying because they carry the parameters they were made with.
Upgrading in place
The standard pattern: on a successful login you have the plaintext password for a moment. If the stored hash used weaker parameters than your current policy, rehash and store the new one right there. Over a few months, active accounts migrate themselves, and you never have to force a password reset.
A note on timing here
The elapsed time shown is for this browser, in WebAssembly, on this machine. It is a useful relative signal — Argon2id at 19 MiB versus bcrypt at cost 12 — but do not use it to choose production parameters. Measure those on the hardware that will actually serve logins.
Frequently asked questions
Which algorithm should I use?
Argon2id, unless something in your stack forbids it. It is memory-hard, so an attacker with GPUs or custom hardware gains far less than they do against a purely computational hash, and the id variant resists both side-channel and time-memory trade-off attacks. bcrypt remains a defensible second choice — it is everywhere, well understood, and still holding up. PBKDF2 only where a compliance regime names it.
Why is a general-purpose hash like SHA-256 wrong for passwords?
Because it is fast, and speed is the attacker's asset. A modern GPU computes billions of SHA-256 hashes per second, so a stolen database of SHA-256 passwords is cracked at that rate. Password hashes are deliberately slow and memory-hungry to make each guess expensive. The difference is not marginal — it is the difference between a leak being survivable and being total.
What should I set the cost parameters to?
As high as your login latency budget allows. The usual target is around 250-500 ms per hash on your production hardware — enough to be imperceptible to a user logging in once, and ruinous to someone making billions of attempts. Measure on the machine that will run it, not this one.
Do I need to store the salt separately?
No. Every scheme here emits a PHC-format string that already contains the algorithm, its parameters and the salt alongside the digest. Store that one string. It is also what makes upgrades possible: when you raise the cost later, existing hashes still verify because their own parameters travel with them.