Password Hash Speed Test
Watch SHA-256, PBKDF2 and bcrypt race on the same input.
Password Hashing Parameter Calculator
Picking a password hash is two decisions, and most advice only covers the first. <strong>Which algorithm</strong> is settled: OWASP puts Argon2id first, then scrypt, then PBKDF2 for FIPS environments, and classifies <strong>bcrypt as legacy-only</strong> — a demotion that contradicts a great deal of older internet advice. <strong>Which parameters</strong> is the harder question, because the right answer depends on your hardware and your latency budget. This tool benchmarks OWASP's recommended parameter sets on the device you are using right now and tells you which one fits. Everything runs locally; no password is involved and nothing is uploaded.
OWASP preference order:
- Argon2id — use this unless you have a reason not to
- scrypt — when Argon2id is unavailable
- PBKDF2 — when FIPS-140 compliance is required
- bcrypt — legacy systems only
How long a single password verification may take. Interactive logins commonly tolerate 250–1000 ms. Higher is more resistant to offline cracking, but also more expensive to serve and easier to abuse for denial of service.
| Algorithm | Parameters | Measured | Verdict | Fidelity |
|---|
How to read these numbers. PBKDF2 runs on the browser's native Web Crypto implementation and is broadly representative. Argon2id runs as WebAssembly, which is close to native speed. bcrypt runs as pure JavaScript (bcryptjs), which is materially slower than a native server implementation — treat its timings as an upper bound on cost, not a prediction of your server. Above all, this measures your current device; a production server is usually faster than a laptop and much faster than a phone. Re-run this on hardware that resembles production before committing to a setting.
scrypt parameters (reference)
scrypt has no Web Crypto primitive, so it is not benchmarked here rather than shipping a misleading pure-JavaScript timing. These are the OWASP-recommended sets, each considered equivalent in strength — pick based on how much memory you can afford per hash:
How to Use This Tool
- Set your verification-time budget — how long one password check may take. Start at 250 ms if you have no constraint in mind.
- Run the benchmark — it measures each OWASP-recommended parameter set for Argon2id, PBKDF2 and bcrypt on this device, one at a time.
- Read the recommendation — it picks the strongest algorithm whose recommended parameters fit your budget, preferring the slowest configuration that still fits.
- Re-check on production-like hardware — a laptop is not a server. Confirm the setting where it will actually run before committing to it.
Why Parameters Matter More Than Algorithm Choice
A password hash is deliberately slow. That is the entire point: it is the only defence that still works after an attacker has your database, because it makes each guess expensive. The algorithm determines what kind of expensive — bcrypt and PBKDF2 are primarily CPU-bound, while Argon2id and scrypt are also memory-hard, which is what makes them resistant to the GPU and ASIC farms that make CPU-only hashing cheap to parallelise. That memory-hardness is the reason OWASP now ranks Argon2id first and bcrypt last.
But an algorithm with weak parameters is worse than a lesser algorithm with strong ones. Argon2id at trivial memory is not meaningfully better than bcrypt at cost 12, and PBKDF2 at the 1,000 iterations someone hard-coded in 2013 is close to useless against modern hardware. The recommended iteration counts climb every few years precisely because attacker hardware does — which is why the parameters belong stored alongside each hash, in the encoded hash string, rather than as a global constant you have to migrate all at once. Every modern format does this, and it is what lets you raise the cost for a user transparently on their next successful login.
The remaining question is how far you can push before your own users feel it. That is not answerable from a table, because it depends on your hardware and your peak login rate: the same Argon2id setting that takes 60 ms on a server might take 400 ms on a low-end phone, and every concurrent login holds that memory for the duration. The honest method is to measure on hardware resembling production, pick the slowest configuration inside your latency budget, and revisit it when you upgrade. That is what this tool automates for the recommended sets.
Frequently Asked Questions
Which password hashing algorithm should I use?
Argon2id, unless you have a specific reason not to. The OWASP Password Storage Cheat Sheet lists the preference order as Argon2id first, then scrypt when Argon2id is unavailable, then PBKDF2 when FIPS-140 compliance is required, and finally bcrypt for legacy systems only. That last classification surprises people, because a lot of widely-circulated advice from the 2010s treats bcrypt as the default choice. Bcrypt is not broken, and an existing bcrypt deployment at a sane cost factor is not an emergency — but if you are choosing today, choose Argon2id.
What Argon2id parameters does OWASP recommend?
Five configurations, all considered equivalent in strength, expressed as memory (m), iterations (t) and parallelism (p):
m=46 MiB, t=1, p=1; m=19 MiB, t=2, p=1; m=12 MiB, t=3, p=1; m=9 MiB, t=4, p=1; and m=7 MiB, t=5, p=1. They trade memory against time — pick based on how much memory you can afford to spend per concurrent hash. Note that the first two are specified for Argon2id and should not be used with Argon2i.What are the current PBKDF2 iteration counts?
OWASP recommends 600,000 iterations for PBKDF2-HMAC-SHA256 and 220,000 for PBKDF2-HMAC-SHA512. PBKDF2-HMAC-SHA1 is listed at 1,400,000 iterations and is for legacy use only. These numbers climb over time as hardware gets faster, so a value you hard-coded years ago is probably now too low — that is a good reason to store the parameters alongside each hash rather than assuming a global constant.
What bcrypt cost factor should I use?
OWASP specifies a minimum work factor of 10, and as high as your server performance allows. Two bcrypt-specific traps matter more than the exact number. First, bcrypt truncates input at 72 bytes — anything past that is silently ignored, which turns a long passphrase into a shorter one. Second, if you pre-hash to work around that limit, do it carefully: OWASP's guidance is
bcrypt(base64(hmac-sha384(data:$password, key:$pepper)), $salt, $cost), because a naive pre-hash reintroduces password-shucking risk.Why do the numbers in this tool differ from my server?
Because they are measured on your current device with browser implementations. PBKDF2 uses the browser's native Web Crypto and is broadly representative. Argon2id runs as WebAssembly, close to native speed. bcrypt runs as pure JavaScript, which is materially slower than a native server implementation — read its timings as an upper bound on cost rather than a server prediction. And a laptop or phone is generally slower than a production server. Use this to understand the shape of the tradeoff and to narrow the range, then confirm on hardware that resembles production.
How long should password verification take?
There is no single correct value, which is why this tool takes a budget rather than printing one number. Interactive logins commonly tolerate 250–1000 ms. Slower means more work per guess for an attacker who has stolen your database, but it also costs you real server capacity and widens a denial-of-service surface, since every login attempt spends that time. Pick the slowest setting your latency budget and your peak login rate can absorb, then revisit it when you upgrade hardware.
Is my data sent anywhere?
No. The benchmark hashes a fixed placeholder string, not anything you type, and every measurement runs in your browser. No password is required to use this tool and nothing is transmitted to Janeer or any server.