What this does
Argon2 has three independent cost parameters instead of bcrypt's single cost factor: memory size, iteration count (time cost), and parallelism (degree of parallel lanes). This tool fixes memory and parallelism at whatever you set, then benchmarks real Argon2id hashes at increasing iteration counts, timed live in your browser, and extrapolates an iteration count for whatever target time you enter.
Why memory is the parameter that actually matters most
Argon2 is a memory-hard function — its resistance to GPU and ASIC cracking comes from forcing every guess to allocate and touch the full memory size, not just spend CPU time, which is exactly what makes it the algorithm OWASP recommends ahead of bcrypt. A higher iteration count at low memory buys far less real security than the same wall-clock time spent at higher memory, because cheap, massively parallel cracking hardware is memory-constrained, not CPU-constrained. Pick a memory size your server can afford per concurrent login first, then use this tool to find the iteration count that fits your time budget at that memory size — not the other way around.
Why the recommendation isn't the final answer
This benchmark measures WebAssembly Argon2id running in your browser's JavaScript engine, on whatever device you're reading this on — not your production server's native Argon2 binding (a compiled library in Node, Python, Go, or similar), which can be meaningfully faster or slower depending on hardware and implementation. Treat the recommended iteration count here as a starting point for understanding the relationship, not as the number to paste directly into production. The two code snippets below run the same kind of benchmark server-side, in Node.js and Python, using the actual libraries a real deployment would use — that's the number that actually matters.
How the extrapolation works
At a fixed memory size and parallelism, Argon2's iteration count is a linear work multiplier — doubling iterations roughly doubles time, unlike bcrypt's cost factor, which is a base-2 exponent. This anchors on the highest iteration count it actually measured and extrapolates using that linear relationship: time(iterations) ≈ time(anchor) × (iterations ÷ anchor_iterations). The benchmark stops automatically once a single iteration count takes about a second, both to keep the browser responsive and because that's already a reliable anchor point.
The OWASP reference profiles
The table above lists all four of OWASP's Password Storage Cheat Sheet Argon2id configurations side by side — each one trades memory for iterations differently, and all four are considered acceptable minimums. The default (highest memory, fewest iterations) is the right starting point unless your server genuinely can't spare 19 MiB per concurrent login hash, in which case one of the lower-memory alternatives trades some of that memory-hardness for a smaller footprint.
FAQ
Is anything sent anywhere?
No — the benchmark and every hash computed here run entirely in your browser.
Should I use Argon2id, Argon2i, or Argon2d?
Argon2id, which this tool benchmarks, is the variant OWASP recommends for password hashing — it combines Argon2i's resistance to side-channel timing attacks with Argon2d's resistance to GPU cracking. See Argon2 Explained for what each variant actually trades off.
How does this compare to bcrypt?
See Bcrypt vs Argon2 for the full comparison, or Bcrypt Cost Calculator to benchmark bcrypt the same way this tool benchmarks Argon2.
I just want to generate an Argon2 hash with specific parameters
See Password Hash Generator, which also covers bcrypt, scrypt, and PBKDF2.
I have an existing hash and want to know its parameters
Password Hash Inspector decodes an existing Argon2 hash's variant, memory size, iterations, parallelism, and salt — and flags parameters below OWASP's minimums automatically.
Why does the benchmark start over at one iteration instead of resuming?
Each run uses a fresh random salt and includes a throwaway warm-up call, so early WASM/JIT startup costs don't skew the first real reading. Re-running gives a second, independent measurement if the first looked noisy.