Argon2 Generator & Verifier

Create and verify Argon2 password hashes – in all three variants – and see what every single parameter in the hash means. Everything runs locally in your browser.

How an Argon2 hash is built

Argon2 writes its hashes in the PHC string format – named after the Password Hashing Competition that Argon2 won in 2015. Unlike bcrypt the length is not fixed, because salt and digest can be sized freely. The structure is just as strict though:

$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQxMjM0NTY$RdescudvJCsgt3ub+b+dWRWJTmaaJObGtL8kZ1kZ2xY
└────────┘└───┘└──────┘└──┘└──┘└──────────────────┘└─────────────────────────────────────────┘
     │      │      │     │   │           │                              │
     │      │      │     │   │           │                              └── Digest, Base64 without padding
     │      │      │     │   │           └── Salt, Base64 without padding
     │      │      │     │   └── Parallelism (lanes)
     │      │      │     └── Iterations
     │      │      └── Memory: 65,536 KiB = 64 MiB
     │      └── Version 1.3
     └── Variant

Note the Base64 at the end: it appears without “=” padding – that is what the PHC specification prescribes. Anyone taking an Argon2 hash apart has to add the padding back before decoding, otherwise every standard Base64 function fails.

The three variants

Argon2id is the hybrid variant and, per RFC 9106, the first choice for passwords. Its first half-pass is data-independent, the rest data-dependent – combining the strengths of the other two. Unless you have a compelling reason for something else, take this one.

Argon2i accesses memory in a pattern that does not depend on the password. So even an attacker able to observe the access pattern learns nothing about the password – say through a side channel on shared hardware. The price: against attackers with lots of parallel compute, Argon2i is weaker than Argon2d.

Argon2d accesses memory in a data-dependent way and resists graphics-card and custom-chip attacks best, but is vulnerable to side-channel attacks in exchange. It is meant for applications without that risk, such as cryptocurrencies – for passwords in a web application it is the wrong choice.

What m, t and p mean

m (memory) is the parameter that sets Argon2 apart from older schemes. It states how much working memory in KiB a single computation occupies. That is exactly what slows attackers down: anyone wanting to spread guessing across thousands of graphics-card cores needs that memory per concurrent attempt. bcrypt has no equivalent – which is why Argon2 is considered the more modern approach.

t (iterations) sets how often that memory is passed over. This is a linear factor: twice the passes, twice the computation time. The recommendation is to raise memory as high as tolerable first and only then turn up t.

p (parallelism) is the number of lanes the work is spread across. Importantly, the value is part of the hash. Verification must use the same number or the result differs – regardless of how many cores the verifying machine happens to have.

Which values make sense?

RFC 9106 names two profiles: 2 GiB of memory with t=1 and p=4, or – if that much memory is not available – 64 MiB with t=3 and p=4. The OWASP Password Storage Cheat Sheet names 19 MiB with t=2 and p=1 as a practical lower bound. All three are available above as presets; the 2 GiB profile is not, because browsers do not hand that much contiguous memory to a WebAssembly computation.

FAQ

Argon2 or bcrypt?
For new systems Argon2id is considered the first choice, because on top of computation time it also drives up memory usage and thereby slows down special-purpose hardware. That does not make bcrypt broken: it has been in use since 1999 and is thoroughly studied. If you already use bcrypt, there is no urgent need to act. For bcrypt there is a dedicated tool at bcrypt.rellit.de.

Why do some hashes have no “v=”?
Those hashes predate 2016 and are implicitly version 1.0. That version has a known weakness and was replaced by 1.3 (v=19). If you find such hashes in a database, they should be recomputed on the next successful login.

Can an Argon2 hash be reversed?
No. Argon2 is a one-way function, not encryption. Verifying means: run the entered password through exactly the same parameters and the same salt again and compare. That is why all parameters sit in the hash in the open – without them a later check would be impossible.

Why does computation take longer here than on my server?
Because it runs in WebAssembly on a single browser thread. The p parameter does spread the work across several lanes computationally, but not across several cores. So take the displayed time as a rough indication, not as a measurement for your production environment.

Is my input uploaded anywhere?
No. The computation is done by a WebAssembly module directly in your browser. There is no server that could see your password or your hash. Still: real production passwords do not belong in any web tool, including this one.