b2KIT

Argon2 Hash Generator

Generate Argon2id password hashes with configurable memory, iterations, and parallelism parameters.

Tested tool guide Tested browser tools Checked August 15, 2026

What Argon2 Hash Generator does and how it behaves

This tool runs the Argon2id key derivation function on a password you type, producing a self-describing hash string in PHC format ($argon2id$v=19$m=...,t=...,p=...$salt$hash). You set the memory cost in KiB, the number of iterations, the parallelism (lanes), and the output length; a random salt is generated automatically unless you supply one. The most common surprise: hashing the same password twice gives two different strings, because the salt changes each run - that's correct behavior, not a bug, and matching hashes require the same salt, variant, and cost parameters.

How the result is produced

1

Cost parameters

Memory cost (m, in KiB) sets how much RAM the function must touch, and iterations (t) sets how many passes it makes over that memory; raising either increases the time and hardware cost of both legitimate verification and offline guessing, at the price of slower logins and more browser memory use. Parallelism (p) sets the number of independent lanes the same memory pool is divided across - at fixed m and t, raising p mainly shortens wall-clock time on multi-core hardware rather than increasing total memory or guessing cost, so it should not be tuned as a substitute for m or t.

2

PHC output string

The result is encoded as a single PHC-format string: algorithm identifier, version, the m/t/p parameters, then base64-encoded salt and base64-encoded hash, each separated by $. That single string carries everything needed to re-verify the password later, so it is what you store in a database field, not the raw hash bytes alone.

Good uses

  • producing an Argon2id hash to store in a user table when building password authentication for a new app
  • confirming that a server-side Argon2 library (argon2-cffi, node-argon2, libsodium's crypto_pwhash) reproduces the expected hash given a fixed salt and matching parameters
  • trying out how raising memory or iteration cost changes hashing time before locking in production parameters

Limits and checks

  • each run generates a fresh random salt by default, so re-hashing the same password will not reproduce a prior hash unless the salt is fixed or copied over
  • the tool only produces argon2id, so it will not match a system expecting argon2i or argon2d output even with identical password and parameters
  • large memory-cost values run against the browser tab's own memory and can be slow or unresponsive on phones or low-RAM machines, since Argon2 is deliberately memory-hard

Common questions

Will this hash match what my server's Argon2 library produces for the same password?

Yes, but only if the salt, variant (argon2id), memory cost, iterations, parallelism, and output length are all identical, since Argon2 is a deterministic function of those inputs plus the salt. If you let the tool pick a random salt, note it down or copy the full PHC string, otherwise your server-side comparison will not line up.

What memory, iteration, and parallelism values should I use?

This tool does not pick safe values for you. OWASP's current Password Storage Cheat Sheet gives baseline Argon2id configurations balancing login latency against resistance to offline cracking; use it as a starting point and adjust based on your server's actual hashing time budget, since the right values depend on your hardware.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools