Argon2 Hash Generator & Verifier
Generate Argon2id, Argon2i and Argon2d hashes and verify passwords against existing hashes — entirely in your browser. Decode any Argon2 PHC string, check its parameters against OWASP minimums, and calibrate the iteration count for your hardware.
Runs in your browser — your password never leaves this tab.
Argon2 is computed locally by WebAssembly (hash-wasm) inside a Web Worker, so the page stays responsive. Nothing is sent to our API and nothing is logged. The only network activity is this page fetching its own Argon2 script the first time you hash; after that, hashing is completely offline. Watch DevTools → Network while you hash: no request ever carries your password, the random 16-byte salt or the resulting hash.
Hash Generation Settings
Prefilled with the demo password correct horse battery staple, already hashed on the right.
RFC 9106 and OWASP both specify Argon2id for password storage. Argon2d is a KDF variant — do not store passwords with it.
Total memory per hash: 64 MiB (m=65536 KiB). The 1 lane split this memory between them — lanes never multiply it.
Security level: Strong (≥ 64 MiB) — derived from m and t against the OWASP Argon2id configurations.
Server capacity: 100 concurrent logins at this setting need about 6.3 GiB of RAM on your auth server.
Generated Hash
Generated hash will appear here
Enter a password and click "Generate Hash" to start
About Argon2
Argon2id: hybrid — Argon2i for the first half-pass, Argon2d after. The RFC 9106 and OWASP choice for passwords.
Argon2i: data-independent addressing, side-channel resistant, weaker against GPUs at low t.
Argon2d: data-dependent addressing, fastest, for key derivation — not for stored passwords.
Memory cost (m): total KiB one hash occupies. This is the parameter attackers with GPUs and ASICs hate most.
Time cost (t): number of passes over that memory; runtime is roughly linear in t.
Parallelism (p): number of lanes the memory is split into. It changes the digest, and OWASP specifies p=1.
About Argon2 Hash Generator & Verifier
The Argon2 Hash Generator & Verifier creates Argon2 password hashes and verifies passwords against existing ones, running the algorithm as WebAssembly inside your browser so nothing is transmitted. Argon2 is the winner of the Password Hashing Competition and the algorithm RFC 9106 and the OWASP Password Storage Cheat Sheet specify for password storage, with three cost parameters — memory (m), iterations (t) and lanes (p) — that let you price an attacker out of GPU and ASIC cracking.
Why use a Argon2 Hash Generator & Verifier?
Argon2id is memory-hard: every hash attempt has to allocate and fill tens or hundreds of mebibytes, which is exactly the resource that makes GPU and ASIC cracking rigs expensive. This tool also decodes any Argon2 PHC string you paste, shows the parameters it actually encodes, grades them against the OWASP-accepted configurations, and tells you when a stored hash should be upgraded on next login — the parameter audit you cannot get from a plain hashing form.
Who is it for?
Backend and security engineers choosing Argon2 parameters, teams auditing the hashes already sitting in their user table, and anyone migrating from bcrypt, scrypt or PBKDF2 who needs to see what a stored digest really contains. Also useful when writing tests: a real encoded hash, generated locally with known parameters, is often all a fixture needs.
How to use the tool
Open the page — a demo password is already hashed in your browser, so a real $argon2id$ string is on screen; click 'Use my own password' to clear it and type your own.
Leave the variant on Argon2id (the RFC 9106 and OWASP choice for password storage); pick Argon2i or Argon2d only for the niche cases described in the FAQ.
Apply a preset — OWASP minimum (m=19456, t=2, p=1), Recommended (m=65536, t=3, p=1) or Sensitive (m=262144, t=4, p=1) — or set memory, iterations, lanes and digest length by hand.
Read the parameter panel: m is the total memory one hash occupies and the lanes (p) split it, so check the 'concurrent logins' figure against the RAM on your auth server.
Click 'Calibrate t for 250-500 ms' to time real hashes on this device and have the tool pick the iteration count that lands in that window at your chosen memory cost.
Click 'Generate Hash': a fresh 16-byte crypto.getRandomValues salt is used every run, so the same password yields a different string each time. Copy the whole PHC string into one VARCHAR(255) column.
Switch to 'Verify Hash' and paste a stored hash — the tool decodes the variant, version, m, t, p, salt length and digest length and flags anything below OWASP minimums before you verify anything.
Enter the candidate password and click 'Verify Password': a match combined with a 'below recommended' verdict is your cue to rehash with current parameters and overwrite the stored value.
Frequently Asked Questions
How do I generate an Argon2id hash with the right parameters in 2026?
Keep the variant on Argon2id and start from one of OWASP's accepted Argon2id configurations: m=47104 (46 MiB) with t=1, m=19456 (19 MiB) with t=2, or m=12288 (12 MiB) with t=3 — each with p=1. If your auth server has RAM to spare, m=65536 (64 MiB), t=3, p=1 is the stronger default most teams ship. Let the tool draw the 16-byte salt that RFC 9106 recommends, and never reuse one. Store the entire encoded string — $argon2id$v=19$m=65536,t=3,p=1$salt$digest — in a single VARCHAR(255) column, because it already carries everything verification needs. In production, hash inside your own application with a vetted library rather than through any hosted tool.
What is the difference between Argon2id, Argon2i and Argon2d?
Argon2d uses data-dependent memory addressing: it is the fastest and the strongest against GPU cracking, but its access pattern depends on the password, which leaks through side channels. Argon2i uses data-independent addressing, so it is side-channel safe, but published analysis showed weaknesses at low iteration counts. Argon2id is the hybrid RFC 9106 defines: the first half-pass runs in Argon2i mode and everything after it in Argon2d mode, so you get both defences. RFC 9106 and the OWASP Password Storage Cheat Sheet both name Argon2id for password storage; Argon2d belongs in key-derivation contexts where the input is not a secret being verified. The variant is baked into the hash string, so switching means rehashing.
Is it safe to hash a password in this tool?
Yes — this page hashes and verifies entirely inside your browser. The Argon2 implementation is WebAssembly (hash-wasm) executing in a Web Worker on your own machine, and the 16-byte salt comes from crypto.getRandomValues. Your password, the salt and the resulting hash never leave the tab: there is no API call, no logging and no telemetry. Confirm it in DevTools' Network tab — the only thing that loads is this page's own Argon2 script, fetched once like any other asset, and after that hashing is completely offline. Argon2 is deterministic, so the output is bit-for-bit what the reference implementation produces for the same parameters and salt. Even so, production systems should hash inside their own application code; use this tool for development, testing and auditing hashes you already store.
Argon2 vs bcrypt vs scrypt vs PBKDF2 — which should I use?
For new systems, Argon2id first. It is memory-hard, so every guess has to allocate tens or hundreds of MiB — far more punishing for GPU and ASIC rigs than bcrypt's fixed ~4 KiB working set. scrypt is also memory-hard and an acceptable alternative at OWASP's N=2^17, r=8, p=1 (/tools/scrypt-hash-generator-verifier). bcrypt at cost 12 or higher is still cryptographically sound and needs no urgent migration (/tools/bcrypt-hash-generator-verifier). PBKDF2 is the right answer only when FIPS-140 compliance forces it, and then it needs 600,000+ HMAC-SHA-256 iterations (/tools/pbkdf2-hash-generator-verifier). Never store raw MD5, SHA-1 or SHA-256 password digests. The full comparison is in /blog/password-hashing-2026-bcrypt-argon2-scrypt-pbkdf2-guide.
Does raising the parallelism (p) increase the memory a hash uses?
No, and this is the most common Argon2 misconception. m is the total memory one hash occupies, expressed in KiB; p is the number of lanes that memory is divided into. m=65536 with p=4 still uses 64 MiB — the four lanes get 16 MiB each and are filled concurrently where the implementation actually threads them. Multiplying m by p overstates the memory by the lane count and produces a wrong security rating. p also changes the output: the same password, salt, m and t with a different p yields a different digest, so it is not a knob you can retune after the fact without rehashing. OWASP specifies p=1.
How do I upgrade hashes that were stored with weak parameters?
Verify first, then rehash inside the successful-login handler. Decode the stored hash — paste it into Verify mode here — and compare its variant, m, t and p against your current policy. If it falls short, verify the password against the stored parameters as usual and, while you still hold the plaintext in memory, re-hash it with the new parameters and overwrite the column in the same transaction. Users never notice and nobody resets a password. When migrating from bcrypt or PBKDF2 you can instead wrap the legacy digest, storing argon2id(bcrypt(password)), so every record is hardened immediately, then unwrap gradually as users sign in. Always record the algorithm in the stored string, never in a separate config value.
Why does the same password produce a different hash every time?
Because a fresh 16-byte random salt is drawn for every hash. That is intentional: unique salts are what stop one precomputed table from covering every user in a breached database. The salt is not lost — it is base64-encoded into the hash string itself, right after the parameters, so verification reads it back out and nothing extra has to be stored. The leading $argon2id$v=19$m=65536,t=3,p=1$ is the PHC string format: algorithm identifier, version (19 = 0x13 = Argon2 v1.3), then the cost parameters. A hash with no v= segment is Argon2 v1.0 (0x10), which predates the 2015 tradeoff-attack fix and should be rehashed.
How long should an Argon2 hash take, and how do I calibrate it?
Target 250-500 ms per hash on the hardware that will actually run your logins. Below roughly 100 ms, offline cracking of a leaked database gets cheap; above a second, logins feel sluggish and a burst of concurrent sign-ins can starve the CPU. The Calibrate button here times real hashes and picks the iteration count that lands in that window on this device — treat it as an upper bound on duration, since browser WebAssembly is usually slower than a native server build, and re-run the benchmark in production. Budget memory too: 100 concurrent logins at m=65536 need about 6.3 GiB of RAM. Re-benchmark every 12-24 months as hardware gets faster.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.