Argon2 Hash Generator: Create and Verify Argon2id Password Hashes Online

If you are building any system that stores user credentials, you already know the golden rule: never store plain-text passwords. What you need is a deliberately slow, memory-hard hash — and today, Argon2id is the algorithm the industry converges on. It won the Password Hashing Competition in 2015 and is now the recommended choice in OWASP guidance, ahead of bcrypt and PBKDF2.

Our free Argon2 Hash Generator lets you generate and verify Argon2id hashes directly in your browser. The hashing engine is compiled to WebAssembly and runs entirely on your machine — your password never leaves the tab. You get full control over the three cost parameters (memory, time, and parallelism), a freshly random 16-byte salt for every hash, and a built-in verifier for checking an existing hash against a candidate password.

Whether you are seeding test fixtures, verifying a hash exported from your database, or learning how the PHC string format works, this tool gives you correct, standards-compliant output in seconds — no SDK, no command line, and zero data exfiltration risk.

Why Use Argon2 Hash Generator?

• True Argon2id, not a look-alike. The tool runs the reference Argon2 algorithm compiled to WebAssembly, producing the exact same output your backend library (argon2-cffi, node-argon2, libargon2) would produce for identical parameters and salt.
• 100% client-side privacy. Passwords, salts, and hashes are computed in your browser tab. Nothing is transmitted, logged, or stored on any server — you can even disconnect from the network and it still works.
• Tunable cost parameters. Choose memory from 16 MiB up to 256 MiB, set 1–8 iterations, and pick a parallelism factor of 1, 2, or 4 to match your production configuration or your hardware budget.
• Fresh salt every time. Each hash is generated with a cryptographically random 16-byte salt from crypto.getRandomValues, so hashing the same password twice yields two completely different PHC strings — exactly as it should be.
• Built-in verifier. The verify mode recomputes the hash from the parameters embedded in an existing PHC string and tells you whether the password matches — a safe way to sanity-check database exports.
• Free and registration-free. No account, no API key, no usage limits. Open the page, hash, copy, done.

Key Features

A few of these deserve a closer look:

• The PHC string output bundles the algorithm, version, and all three cost parameters alongside the salt and digest. That means a hash generated here is self-describing — paste it into your user table and any compliant verifier can recompute it later without external configuration.
• Version 19 (0x13) is the final Argon2 version, and that is what the tool emits, so you will never accidentally mix old pre-standard hashes into a new system.
• The verify tab parses the hash you paste, extracts its own salt and parameters, and recomputes — it does not assume your current UI settings, which mirrors how real verification code should behave.

How to Use

1. Open the Argon2 Hash Generator. No sign-up or installation is required; the WASM module loads with the page.
2. Enter the password you want to hash in the input field. Use a realistic test string if you are generating fixtures, or a real credential only if your environment is trusted (again — it never leaves your browser).
3. Tune the parameters if needed. The defaults (64 MiB memory, 3 iterations, parallelism 1) match OWASP's baseline recommendation for interactive logins. Raise them if your production config is more aggressive.
4. Click Generate Argon2id Hash and copy the resulting PHC string from the result box. A new random salt is used on every click, so each output is unique.
5. (Optional) Switch to the verify tab, paste the PHC string plus the candidate password, and confirm you get a match. This is the quickest way to prove a hash round-trips correctly before wiring it into your app.

Understanding Argon2 Parameters

Argon2's strength comes from making hashing expensive in configurable ways. Unlike SHA-256 — which modern GPUs compute billions of times per second — Argon2 lets you price an attack in both time and silicon.

Memory cost (m)

The m parameter sets how much RAM each hash computation consumes. Memory hardness is Argon2's killer feature: GPUs and ASICs have abundant arithmetic units but limited fast memory per core, so forcing, say, 64 MiB per attempt makes massively parallel cracking rigs dramatically less effective. The tool offers 16 to 256 MiB; OWASP currently recommends at least 19 MiB (19,456 KiB) for interactive authentication, with more memory always being the better trade if your servers can afford it.

Time cost (t)

Iterations control how many passes the algorithm makes over its memory. More passes mean more CPU time per hash — for both your legitimate login flow and an attacker's guesses. The sweet spot is the highest value that keeps your production login latency acceptable (commonly under ~250–500 ms). The tool's range of 1–8 with a default of 3 covers typical production settings.

Parallelism (p)

The p parameter (lanes) splits the work across threads. It primarily affects how well the computation uses multi-core hardware; increasing it changes the output, but on its own it is the least security-relevant of the three knobs. Match it to your backend library's configured value so hashes verify consistently.

Salt and the PHC string format

Every hash uses a fresh random 16-byte salt, which defeats rainbow tables: an attacker cannot precompute anything useful if every password hashes differently. The output is a PHC string format hash such as:

$argon2id$v=19$m=65536,t=3,p=1$U2FsdGVk...base64-salt$U2FsdGVk...base64-digest

Read it left to right: algorithm (argon2id), version (v=19), then the cost parameters (m, t, p), then the salt, then the digest — all Base64-encoded without padding. Because the parameters travel inside the string, you can safely raise defaults over the years and old hashes still verify.

Why Argon2id and not Argon2i or Argon2d?

Argon2 has three variants. Argon2d maximizes resistance to GPU cracking but leaks memory-access patterns, making it vulnerable to side-channel attacks. Argon2i is side-channel-safe but weaker against GPUs. Argon2id is the hybrid: it uses Argon2i passes first, then Argon2d passes, giving you the best of both. RFC 9106 recommends Argon2id as the default, and that is what this tool generates.

Practical Use Cases

Seeding development and test fixtures

Need a realistic $argon2id$... value for a local database seed or an integration test? Generate a hash for Test1234!, paste it into your fixture file, and your auth flow exercises the same verification path it will in production — including PHC string parsing.

Verifying hashes exported from production

Migrating off a legacy system or debugging a login failure? Paste the PHC hash from your user table into the verify tab along with the password from your staging copy. A match proves the hash and its embedded parameters are intact; a mismatch points you at data corruption or a misconfigured import.

Learning and documentation

Writing onboarding docs or teaching a security module? The tool is a live sandbox for showing students and new hires what parameter changes do: bump memory from 16 to 256 MiB and watch hashing slow to a crawl; change a single character of the password and see the entire digest change.

Cross-checking backend implementations

If your backend uses node-argon2, argon2-cffi, or PHP's password_hash() with PASSWORD_ARGON2ID, hashes generated here with the same parameters should verify there — and vice versa. The tool is a quick interoperability check before you commit to a library.

Best Practices

• Match your production settings. If your server hashes with m=65536,t=3,p=1, verify against hashes with exactly those parameters — Argon2 output changes with every parameter, by design.
• Prefer memory over iterations. When you can afford to harden only one axis, increase m first; memory hardness is what hurts GPUs most.
• Never trim or normalize the password before hashing (and when verifying, compare the full PHC string parameters, not just the digest).
• Let the library handle salts. The tool generates one automatically; your backend should too. Never reuse a salt across users, and never store it separately from the PHC string.
• Plan for rehashing. Store the PHC string as-is; when hardware improves, raise your defaults and transparently rehash on next successful login.
• Keep secrets out of logs. The tool keeps everything client-side, but the moment you paste a hash into a ticket or chat, you have moved the risk — treat PHC strings as sensitive configuration.

Ready to Hash?

Open the free Argon2 Hash Generator and produce your first Argon2id hash in under ten seconds — tunable parameters, automatic salts, and a built-in verifier, all running privately in your browser. Your users' passwords deserve more than a fast hash; give them a deliberately expensive one.

Related Tools You Might Like:

• Bcrypt Generator — the classic blowfish-based password hash, still widely deployed
• Password Hash Verifier — identify and validate hash formats
• TOTP Generator — generate time-based one-time passwords for 2FA testing

Frequently Asked Questions

Q: Is my password sent to a server?

A: No. The Argon2 algorithm runs in your browser via WebAssembly. The password, salt, and resulting hash never leave your device, and the tool works even with your network disconnected.

Q: What are good Argon2id parameters for production logins?

A: OWASP's current baseline is m=19,456 KiB (19 MiB), t=2, p=1. The tool's default of 64 MiB, 3 iterations, parallelism 1 is a comfortable step above that. Choose the highest settings that keep your login latency under roughly 250–500 ms.

Q: Why does the same password produce a different hash every time?

A: Each run uses a fresh random 16-byte salt. This is intentional — it defeats precomputed rainbow tables. Verification works because the salt travels inside the PHC string.

Q: Can I verify a hash that was created by my backend library?

A: Yes. Paste any Argon2id PHC string into the verify tab along with the candidate password. The tool reads the salt and parameters embedded in the string and recomputes, exactly like a compliant backend verifier.

Q: Argon2id vs bcrypt — which should I choose?

A: For new systems, Argon2id is the modern recommendation (RFC 9106, OWASP) because its memory hardness resists GPU cracking better than bcrypt. Bcrypt remains acceptable and battle-tested, but new deployments should prefer Argon2id where the runtime supports it.

Happy hashing!