Argon2 Hash Generator & Verifier (Argon2id)
Hash a password with Argon2id, Argon2i or Argon2d and get the $argon2id$ PHC string, or check a password against one. Runs in your browser.
The secret and associated data are rarely used; neither is recorded in the $argon2…$ string.
The salt must be 8 to 1024 bytes long.
Checked against libargon2 (the reference C code) and the RFC 9106 test vectors. Runs entirely in your browser.
How to use
- Type the password (or give it as hex), and enter a salt or press Random salt for 16 fresh bytes.
- Pick a preset or set the variant, memory, passes, parallelism and tag length yourself, then press Hash; long settings show progress and can be cancelled.
- To check a stored hash, switch to Verify, paste the $argon2…$ string and the password (and the secret if one was used), and press Verify.
About this tool
ShowHide
Argon2 won the Password Hashing Competition in 2015 and is specified in RFC 9106; Argon2id is the variant OWASP recommends for storing passwords. This tool is a complete implementation written for the page: it takes the password, a salt of at least 8 bytes, the memory cost in KiB, the number of passes and the degree of parallelism, and produces the raw tag in hex and base64 together with the $argon2id$v=19$m=…,t=…,p=…$salt$hash string that libargon2, argon2-cffi, PHP's password_hash and the Node argon2 package all store and read. The verify side parses such a string, recomputes it and tells you whether the password matches. Argon2d, Argon2i and the older version 1.0 (v=16) are supported for compatibility, as are the optional secret key and associated data of the RFC. Lanes are computed one after another rather than in threads, so p=4 gives the same answer as a server with four cores but takes four times as long as one lane. Memory actually used is rounded down to a multiple of 4·p KiB, exactly as the reference code does. The ceiling is 256 MiB, because a browser tab cannot reliably allocate more in one piece; the RFC's first recommended setting (2 GiB) therefore cannot be run here. Nothing is uploaded, and the password and the secret are never written to local storage.
Frequently asked questions
Which settings should I use?
OWASP's current minimum is Argon2id with 19 MiB of memory, 2 passes and parallelism 1; RFC 9106's second recommendation is 64 MiB, 3 passes and 4 lanes. Both are one click away. The right figure is the largest memory your login server can afford per concurrent request, tuned so one hash takes well under a second there.
Why is it slower here than on my server?
The page runs in plain JavaScript on one thread and computes the lanes one after another, while libargon2 uses optimised native code and one thread per lane. The output is identical; only the time differs, so the timing shown is not a benchmark of your production setting.
Why does the same password give a different hash each time?
Because the salt is part of the input. With a fixed salt the output is deterministic, and that is how verification works: the salt and every parameter are stored in the $argon2id$ string, so the verifier can repeat the exact computation.
Where do the secret key and associated data go?
Into the first hash H0, as RFC 9106 defines. Neither is written into the PHC string, so a hash made with a secret can only be verified by someone who supplies the same secret; a server keeps it outside the database as a pepper.
Argon2id, Argon2i or Argon2d?
Argon2id for passwords. Argon2d chooses memory blocks from the data it is hashing, which resists GPU cracking best but can leak timing information about the password; Argon2i avoids that leak but is weaker against time-memory trade-off attacks. Argon2id runs the first half of the first pass like Argon2i and the rest like Argon2d.
Related tools
PBKDF2 Key Derivation
Derive a key from a password with PBKDF2-HMAC in your browser — pick the hash, iteration count and output length, and read the result as hex or Base64.
Developer
Bcrypt Hash & Verify
Generate bcrypt hashes with adjustable cost factor, or verify an existing hash against a password — runs entirely in your browser.
Developer
scrypt Key Derivation (RFC 7914)
Derive a key from a password with scrypt in the browser, with the memory cost worked out and the PBKDF2 and ROMix stages shown.
Developer
File Hash Verifier
Drop a file and paste an expected SHA-1 / 256 / 384 / 512 — see if the actual hash matches. Useful before installing downloaded binaries.
File
PKCS#12 Keystore Inspector
Open a .p12 or .pfx in your browser: MAC and ciphers before the password, then the certificate chain, the private key, and whether they match.
Developer
OAuth 2.0 PKCE Generator
Generate code_verifier + S256/plain code_challenge for OAuth 2.0 PKCE (RFC 7636).
Network