CiphersOnline
Encryption Online
Hashing
Argon2

Argon2 Online - Password Hashing

Generate or verify Argon2id password hashes in your browser. Argon2 is the winner of the Password Hashing Competition (2015), standardized in RFC 9106, and recommended by OWASP for new password storage. Configure memory cost, iterations, parallelism, output length, salt, and variant.

Salt (leave empty for random)
Password
0 chars · 0 bytes
Hash to verify against
Try:
Result
✓ Client-side processing only ✓ Input is not sent to server
Examples
Common password
Variant: argon2id Memory (KiB): 19456 Iterations: 2 Parallelism: 1 Key length (bytes): 32
Input password123

A typical password. Click Compute to generate an Argon2id hash with OWASP-recommended defaults.

Passphrase
Variant: argon2id Memory (KiB): 19456 Iterations: 2 Parallelism: 1 Key length (bytes): 32
Input correct horse battery staple

A long passphrase with high entropy.

High-memory profile
Variant: argon2id Memory (KiB): 47104 Iterations: 1 Parallelism: 1 Key length (bytes): 32
Input summer-2026-admin-login

Argon2id with 47 MiB of memory and one iteration, useful for comparing an OWASP-listed high-memory profile against the default.

Fixed-salt test vector
Variant: argon2id Memory (KiB): 9216 Iterations: 4 Parallelism: 1 Key length (bytes): 32 Salt (leave empty for random): example-fixed-salt
Input demo password

Uses a fixed example salt and 9 MiB / 4 iterations so repeated runs are easier to compare. Use random unique salts in production.

What is Argon2?

Argon2 is a password hashing function and key derivation function designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich, and selected as the winner of the Password Hashing Competition in 2015. It is standardized in RFC 9106 and recommended by OWASP for new password storage because it can make every password guess expensive in both CPU time and memory.

The Argon2 family has three variants: Argon2d uses data-dependent memory access and is fast, but it is not the usual choice for web password storage; Argon2i uses data-independent access and is designed to resist side-channel leakage; Argon2id combines both approaches and is the recommended default for login systems, SaaS products, admin panels, and other applications that store user passwords.

Memory-hardness and tunable parameters

What makes Argon2 special is memory-hardness: each password guess requires a configurable block of RAM, not only repeated CPU work. That matters in offline attacks after a database leak, because GPUs and ASICs cannot cheaply run millions of guesses in parallel when each guess must reserve memory.

This Argon2 online tool exposes the parameters developers usually need: memory in KiB, iterations as the time cost, parallelism as lanes, key length for the hash output, an optional salt, and the Argon2 variant. The default settings use Argon2id with 19,456 KiB of memory, 2 iterations, 1 lane, and a 32-byte output, matching the common OWASP baseline for password hashing.

If login latency is too low on your production server, raise memory or iterations; if it is too high, choose one of the accepted lower-latency profiles and document the trade-off. Do not tune on a developer laptop only - benchmark on the same type of server that will process real sign-ins.

PHC output, salts, and verification

Argon2 hashes are usually stored as a PHC encoded string such as $argon2id$v=19$m=19456,t=2,p=1$.... The string stores the algorithm variant, version, memory cost, iteration count, parallelism, salt, and derived hash, so a verifier can check the password later without separate parameter columns.

Use Generate mode to create a new Argon2 password hash for testing, documentation, or comparing parameters. Use Verify mode when you already have a stored Argon2 string and need to check whether a candidate password matches it. For real user accounts, generate a unique random salt for every password and store the full encoded output exactly as produced by your server-side library.

Common Argon2 use cases

Use this Argon2 online generator when you need a quick Argon2id password hash for documentation, test fixtures, migration notes, or comparing parameter choices. It is also useful as an Argon2 verifier: paste a candidate password and an existing encoded hash to confirm whether they match before debugging application code.

Developers commonly arrive here looking for an Argon2id generator, an Argon2 password hash generator, a way to verify an Argon2 hash, an explanation of PHC encoded Argon2 output, or a practical comparison of Argon2 vs bcrypt and PBKDF2. The important takeaway is the same in each case: use Argon2id with a unique salt, store the full encoded string, and choose memory and time costs that your production login flow can sustain.

FAQ

Use Argon2id. It combines data-dependent and data-independent memory access in two passes, gaining the speed of Argon2d and the side-channel resistance of Argon2i. RFC 9106 and OWASP 2024 both recommend Argon2id as the default. Use Argon2i only when side-channel attacks are a primary concern; use Argon2d only when side-channels are guaranteed irrelevant (e.g. cryptocurrencies running on dedicated hardware).

OWASP 2024 lists several acceptable combinations: 19 MiB / 2 / 1, 47 MiB / 1 / 1, or 9 MiB / 4 / 1. Pick the one that gives 100–500 ms on your server — that is slow enough to deter brute-force but fast enough not to ruin login UX. If memory budget is tight, raise iterations; if CPU is tight, raise memory. Parallelism rarely needs to be > 1 outside specific multi-core scenarios.

Argon2 is memory-hard: attackers using GPUs or ASICs cannot reduce their cost by parallelism since each guess still requires the configured amount of memory. bcrypt has only 4 KiB of internal state, and PBKDF2 has effectively none. With 19 MiB per guess (Argon2 default), a GPU with 24 GiB can only run ~1,200 guesses in parallel vs millions for PBKDF2 — a thousandfold defender's advantage.

No. Argon2 runs entirely in your browser using the hash-wasm library (WebAssembly) — your password never leaves your device. No network requests, no logging, no server-side processing. Still: do not use this tool for production hashing of real user accounts — use a server-side library.

Use it for learning, parameter testing, examples, and checking that a stored hash verifies correctly. For production user accounts, hash passwords on your application server with a maintained library, secure randomness, rate limiting, monitoring, and a migration plan for future parameter upgrades.

Yes. A PHC encoded Argon2 string stores the variant, version, memory cost, iterations, parallelism, salt, and hash in one value. Store the full string exactly as generated, for example a value beginning with $argon2id$v=19$..., so the verifier can reproduce the same parameters later.

No. A salt must be unique and random, but it is not a secret. Its job is to make identical passwords produce different hashes and to defeat precomputed lookup tables. Keep the salt with the Argon2 hash, usually inside the PHC encoded output.

Rehash when your stored parameters are weaker than your current policy, when you switch from Argon2i or Argon2d to Argon2id, or when hardware improvements make your old login cost too cheap. A common pattern is to verify the old hash during login, then transparently store a new hash with current parameters after successful authentication.
Related tools

HMAC Generator

Generate an HMAC from text with a secret key in your browser.

All Hashing & Password Security →