Argon2 Hash Verification | Compare a Password Against an Encoded Hash
Enter a password and an existing Argon2 encoded hash ($argon2id$...) to check whether they match. All computation happens in your browser, and nothing is ever sent to a server.
Verifying an Argon2 hash
Argon2 won the Password Hashing Competition in 2015 and is now **the most widely recommended password hash for new work.** Its chief difference from bcrypt is that you can tune **memory usage as well as computation time.** GPUs and purpose-built hardware excel at parallel arithmetic but struggle to give every core a large allocation of memory, so demanding memory raises the cost of a brute-force attack considerably.
An Argon2 hash takes the form `$argon2id$v=19$m=19456,t=2,p=1$salt$digest`, with **the parameters and the salt embedded inside the string itself.** Verification therefore needs no separate parameter list: the hash and the password are enough. This tool performs that verification. **Everything is computed in your browser, and neither the password nor the hash you enter is ever sent to a server.**
How to verify
- Paste the Argon2 hash Enter the encoded string beginning `$argon2id$` exactly as it stands.
- Enter the password Type the plain-text password you want to check against it.
- Run the verification **Because the algorithm is designed to consume a lot of memory, this can take a few seconds.** That is the behaviour working as intended.
- Read the result You are told whether the two match.
Tips for getting more out of it
- Paste the encoded hash (the string starting with $argon2id$) generated by the Argon2 Hash Calculator tool exactly as it is.
- The encoded hash already contains the variant, memory cost, iteration count, and salt, so you don't need to specify any of these parameters separately when verifying.
- If the hash format is invalid (for example, characters lost during copying or stray line breaks), you'll see an error message — double-check that you copied the entire string correctly.
- If you get a mismatch, check whether the password has unintended differences in capitalization or leading/trailing whitespace.
Where this helps
Checking an authentication implementation
Confirm with a known hash-and-password pair that your own login code verifies correctly.
Confirming a migration
Establish in advance whether hashes brought over from another system can be verified as they stand.
Inspecting the chosen parameters
Read the `m`, `t` and `p` values embedded in the string to see what cost was configured.
Round-tripping with the generator
Confirm that a value produced by the Argon2 hash generator verifies correctly here.
Argon2 terms explained
- Argon2id
- The variant combining resistance to side-channel attacks with resistance to GPU attacks. **It is the standard choice for new work.**
- m (memory cost)
- The amount of memory used, given in kibibytes. **This is the central parameter that makes Argon2 resistant to GPU attacks.**
- t (time cost)
- The number of iterations. Raising it lengthens the computation and with it the attacker's cost.
- p (parallelism)
- The number of lanes processed in parallel, set to suit the core count of the server.
- Salt
- Random data varied for every hash. **The same password yields a different hash each time, which defeats rainbow table attacks.**
- Encoded hash
- The format packing algorithm name, parameters, salt and digest into a single string. It carries everything verification needs.
Frequently Asked Questions
Side Note — Why Comparing Hashes Is Enough to Verify a Password
Password verification might sound like it directly compares a stored password with the one you type in, but it actually works quite differently. The server (or, as in this tool, client-side code) re-hashes the password you enter using the same algorithm and the same salt that were used when it was originally stored, and then checks only whether the result matches the stored hash value. The original password itself is never the subject of a "comparison" — the whole process boils down to checking whether two hashes are identical, which is the real advantage of this approach.
This works because hash functions like Argon2 are deterministic: given the same input, salt, and parameters, they always produce the same output. An encoded hash string (in the form $argon2id$v=19$m=...$salt$hash) embeds the salt and every parameter that was used at computation time, so you never need to supply them separately when verifying — the hash string alone is enough to recompute it from scratch.
It's precisely because hashing has these two properties — being "one-way" (you can't work backward from a hash to recover the original password) and "deterministic" (the same input always yields the same output) — that a service can verify logins securely without ever storing users' raw passwords. Even if a database is leaked, all an attacker gets is the hash value, and with a computationally expensive algorithm like Argon2, brute-forcing the original password back out would take an extremely long time.