Argon2 Password Hash Format Explorer

No — the hashes shown are deterministic simulations for educational purposes. For real password hashing use the argon2 npm package server-side or argon2-browser client-side (WebAssembly).

Argon2id is memory-hard, GPU-resistant, and configurable — making brute-force attacks orders of magnitude more expensive. bcrypt is limited to 72-byte passwords and uses a 1999-era design that lacks memory hardness.

PHC (Password Hashing Competition) string format encodes all hash parameters in a single portable string: $algorithm$version$parameters$salt$hash.

Yes, completely free.

Absolutely. The Argon2 Password Hash Format Explorer processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the Argon2 Password Hash Format Explorer is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the Argon2 Password Hash Format Explorer in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The Argon2 Password Hash Format Explorer works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

The three Argon2 variants differ only in how they access memory. Argon2d uses data-dependent access, which gives the strongest resistance to GPU and ASIC cracking but leaks timing information, making it unsafe against side-channel attacks. Argon2i uses data-independent access, defeating side-channel timing attacks but offering weaker resistance to dedicated cracking hardware. Argon2id is a hybrid: it runs the first pass in Argon2i mode and the rest in Argon2d mode, so it gets meaningful protection against both threats at once. That balance is why OWASP and RFC 9106 recommend Argon2id as the default for password storage, with Argon2d reserved for cases like cryptocurrency where side channels are not a concern. Switch between all three in the explorer to see how only the algorithm label in the PHC string changes.

Inside a PHC string you will see a segment like m=65536,t=3,p=4, and each letter is a tuning knob. The t value is time cost, the number of passes Argon2 makes over memory; raising it linearly increases how long every guess takes for both attacker and user. The m value is memory cost in kibibytes, so 65536 means 64 MB of RAM is needed per hash; this is what makes Argon2 memory-hard and starves cheap parallel cracking rigs of bandwidth. The p value is parallelism, the number of independent lanes, ideally matched to your server's CPU threads. OWASP's interactive-login baseline is t=3, m=64MB, p=4, marked with a star in the tool. Adjust each dropdown in the explorer to watch the parameter segment of the PHC string update live.

Tuning Argon2 is about spending as much of an attacker's resources as possible without slowing real logins to a crawl. A practical rule is to first set memory cost as high as your hardware can spare, since memory hardness is Argon2's main defense; 64 MB is the recommended floor for interactive logins, and 128 or 256 MB is reasonable on a well-provisioned server. Set parallelism to roughly match your available CPU threads. Then raise the time cost until a single hash takes about half a second on your production machine, which keeps brute-force expensive while staying responsive. Because every parameter is embedded in the PHC string, you can raise these values later and rehash passwords at next login with no database migration. Use the explorer to preview different parameter combinations and the exact string they produce before committing to a configuration.

The v=19 segment is the Argon2 algorithm version, not a parameter you tune. It refers to Argon2 version 1.3, whose hexadecimal identifier 0x13 equals 19 in decimal. Version 1.3 fixed a weakness present in the original 1.0 design, and it has been the standard ever since, so nearly every modern library emits v=19. Recording the version inside the hash matters because it lets a verifier know exactly which algorithm revision produced a stored password, so older hashes can still be checked correctly even after libraries update. If you ever encounter a hash with no version field, it predates this convention and was likely made with version 1.0. The explorer always outputs v=19 in its breakdown so you can see where the version sits between the algorithm name and the cost parameters.

A salt is a unique random value mixed into each password before hashing, and it appears as the second-to-last base64 segment of the PHC string. Its job is to guarantee that two users with the same password produce completely different hashes, which defeats precomputed rainbow tables and stops an attacker from cracking many accounts at once. Because the salt only needs to be unique, not secret, it is stored in plain sight right inside the hash string itself rather than in a separate column. When someone logs in, the verifier reads the salt back out of the stored string, re-runs Argon2 with it and the embedded cost parameters, and compares the result. This self-contained design means one database field holds everything needed to verify a login. Generate a string in the explorer to see the salt highlighted as its own color-coded part.