Runs entirely in your browser — nothing leaves this page.Password hashing
Derive keys with Argon2id, scrypt, PBKDF2 or bcrypt and see how long each parameter set actually takes.
Tuning password hashing by measurement
Every password-hashing recommendation ends with 'tune the parameters for your hardware'. This tool lets you actually do that: pick Argon2id, scrypt, PBKDF2 or bcrypt, set the parameters, and see the real derivation time next to the derived key.
The defaults are the current OWASP recommendations: Argon2id at 19 MiB with two passes, scrypt at N=2^15, PBKDF2 at 600,000 iterations, bcrypt at cost 10. From there, raise the cost until the timing sits where your login latency budget allows — 100 ms to 500 ms is the usual target for interactive auth.
The timing shown is this device's single JavaScript thread. Your servers run native implementations and differ — treat the number as a relative guide for comparing parameter sets, and confirm the final choice on production hardware.
Which algorithm should a new system use?
Argon2id, per OWASP and the algorithm's own design goals: it costs attackers memory as well as time, which cripples GPU cracking rigs. scrypt is a fine second choice; bcrypt remains acceptable for existing systems; PBKDF2 belongs where FIPS compliance dictates it.
What is the difference between a KDF and a hash?
A hash like SHA-256 is designed to be fast, which is exactly wrong for passwords — an attacker with a GPU tries billions per second. A KDF is deliberately expensive in time (all of these) and memory (Argon2, scrypt), turning each guess from nanoseconds into real work.
Why does my derived key differ from another tool's?
Same algorithm, same password, same salt, same parameters, same output length — change any one and the key changes completely. The usual culprits are a salt pasted as text where hex was expected, or a different iteration count. This tool takes the salt strictly as hex to make the input unambiguous.
Can I use these outputs as encryption keys?
That is what a KDF is for — deriving a key from a passphrase. Derive 32 bytes and use them with AES-256-GCM (the encryption tool here accepts exactly that). Store the salt and parameters alongside the ciphertext; they are not secret.
Why is Argon2 slower here than its reference benchmarks?
The reference implementation is native code with SIMD; this is JavaScript in one thread. The relative cost between parameter sets still holds, which is what you need for tuning — validate the absolute numbers with your server-side library.
Related tools: bcrypt / htpasswd, Encrypt / decrypt and Password generator.