Generate an Argon2 Hash — Free Argon2id/i/d Generator

Every time a user creates an account on your platform, their password becomes a liability unless it is protected by a robust, modern password hashing algorithm. This argon2 hash generator gives you cryptographic argon2 hash output — including the encoded variant, version tag, parameters, salt, and output bytes — all computed entirely in your browser. Understanding the output empowers you to configure production-grade login flows, debug framework integrations, and make informed decisions about tuning parameters that balance protection against login latency on your processing server.

Argon2 Password Hash Generator — Parameters, Output Format, and Encoded Hash Anatomy

Generate Hash with Argon2id, Argon2i, or Argon2d

The generator presents a plaintext input field alongside a variant selector offering argon2id, argon2i, and argon2d. Below the variant selector sit the four cost controls that directly govern the algorithm's work factor. Once you click Generate, the tool runs the full Argon2 algorithm using the WebAssembly reference implementation — nothing leaves your browser. This browser-based approach means no plain text password is stored anywhere; it is a genuinely client-side, runs locally computation.

The five input parameters the tool exposes mirror the RFC 9106 specification exactly:

Memory cost (m)

The memory usage in kibibytes the algorithm allocates per hash operation. Raising memory cost (m) directly increases the cost of GPU parallelisation and ASIC attacks. The current baseline is m=19456 (19 MiB); a stronger setting is m=65536 (64 MiB). As hardware advances, plan to increase this value — the OWASP cheat sheet recommends revisiting tuning parameters at least yearly.

Time cost / iterations (t)

The number of passes the algorithm makes over the allocated memory — the number of iterations, or hash passes, performed. Higher values extend execution time linearly and raise the iterations parameter independently of memory. The OWASP minimum is t=2; the Authelia recommended profile default is t=3. If your processing latency budget is generous, increase time cost before touching memory.

Parallelism (p)

The number of parallel threads — parallelism lanes — the algorithm spawns. Set this equal to the number of CPU cores available on your processing server. Single-threaded mode is the OWASP minimum setup; the Authelia default is p=4. Parallelism does not meaningfully raise attacker cost on its own, but allows the hash to consume multiple cores at verification time.

Salt

A cryptographically secure random value, auto-generated per hash. A minimum salt length of 16 bytes (128-bit) is the accepted guideline. The password salt is auto-generated and the generator defaults to -s 16 (salt size bytes) in line with the Authelia CLI. Never supply a fixed or reused salt — doing so defeats rainbow table resistance entirely.

Output length

The length of the resulting hash output in bytes. Standard output is 32 bytes (256 bits), matching the Authelia default key size. Increase to 64 bytes for higher-assurance applications such as drive-level protected key derivation.

Verify and Output — Reading the Encoded Hash String

After generation, the tool displays the fully encoded hash in the standard PHC string format. The encoded hash format embeds every parameter needed for verification, making the string self-contained for secure credential storage:

$argon2id$v=19$m=65536,t=3,p=4$[base64 salt]$[base64 hash]

Each dollar-sign-delimited segment carries a specific meaning:

• $argon2id$ — variant prefix identifying the argon2id variant (or $argon2i$ / $argon2d$ for the other two modes)
• v=19 — the version indicator, always v=19 for Argon2 version 1.3
• m=65536,t=3,p=4 — the tuning parameters embedded in the hash string format for reproducibility
• [base64 salt] — the Base64-encoded random salt (base64 salt), typically 22 characters for a 16-byte salt
• [base64 hash] — the Base64-encoded output (base64 encoding of the raw output bytes)

The verify tab accepts a saved hash and a plaintext password. The tool decodes the parameter embedding from the encoded output string, re-derives the hash using the recovered salt and parameters, and compares the result in constant time. A pass/fail result confirms whether the plain-text password matches the saved login record. This plain text verification workflow is identical to what your server-side framework performs at login time.

Argon2 Hash Generator & Verifier — Why Argon2 Won the Password Hashing Competition

What Is Password Hashing and Why Plaintext Storage Is Dangerous?

Password hashing is a one-way process that converts a plain-text password into a bit string of a fixed size — a digest — using a cryptographic hash function. A cryptographic hash function is designed to be a one-way operation: infeasible to invert. Storing hashed login data rather than plaintext means that a database breach exposes only the hashed output, not the login details themselves. An attacker who steals hashed output must then perform cracking attacks — processing candidate entries one by one and comparing them to the saved value — rather than simply reading the plaintext. Modern resistant functions make this economically prohibitive at scale. Outdated methods such as md5, sha1, and plain sha256 are not resistant to GPU attacks and can be attacked with parallelisation at billions of guesses per second.

What Is a Key Derivation Function (KDF)?

A key derivation function (KDF) is a specialised cryptographic procedure designed to derive a cryptographic key — or a securely stored login record — from a low-entropy input like a passphrase. Unlike general-purpose digest functions such as SHA-256 or SHA-512, a KDF is intentionally slow and resource-intensive. It accepts input parameters (memory, time, parallelism) that let you tune how expensive each computation is. Argon2 is a KDF; so are bcrypt, scrypt, and PBKDF2. Plain sha-256 or sha-512 without iteration is not a KDF and must never be used for protecting login data. The KDF design pattern also supports key stretching for drive protection, API key hardening, and cryptocurrency key derivation — anywhere a low-entropy passphrase must produce a high-entropy cryptographic key.

The Password Hashing Competition and Argon2's PHC 2015 Victory

The Password Hashing Competition (PHC) was an open competition organised by cryptography and cybersecurity experts to identify a preferred approach for strong password protection. The PHC ran from 2013 to 2015 and attracted 24 candidate algorithms. Argon2 was selected as the final PHC winner on 20 July 2015 — the argon2 winner designation that makes it the de-facto preferred algorithm for modern application development. Argon2 was designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich from the University of Luxembourg. Its design is captured in the argon2 specifications PDF and implemented in the open argon2 source code reference implementation.

Argon2 Variants — Argon2d, Argon2i, and Argon2id Compared

The three argon2 variants differ in how they traverse memory and in what threat model they optimise for. Variant selection has real consequences for identity protection and access control:

Argon2d (argon2d variant)

Uses data-dependent memory access — each memory block's address depends on the content of previous blocks. This maximises resistance to GPU attacks and ASIC attacks at the cost of vulnerability to cache-timing attacks. Best suited for cryptocurrency key derivation and drive-level protection, not interactive login hashing.

Argon2i (argon2i variant)

Uses data-independent memory access, making it resistant to side-channel attacks and suitable for smart cards and HSMs. Slightly weaker against GPU attacks because the memory access pattern is predictable. Recommended for environments where the attacker can observe cache timing. The data-independent mode is less recommended than Argon2id for general-purpose login protection on modern web applications.

Argon2id

The hybrid argon2id variant: the first half of the memory pass uses data-independent memory access (like Argon2i), and the second half uses data-dependent access (like Argon2d). This combination provides resistance to both side-channel attacks and GPU/ASIC brute-force attacks. OWASP, NIST, and RFC 9106 all identify Argon2id as the recommended default for identity verification, access control enforcement, and secure key derivation in modern deployments.

Why Argon2id Is the Default for Password Security

The resistant design of Argon2id means that every candidate an attacker tests must allocate a large block of memory — by default 64 MiB — making GPU parallelisation expensive even on modern hardware. Functions with high memory requirements impose a burden that grows with the number of parallel cracking attempts, so GPU farms and custom ASICs cannot amortise the cost across thousands of simultaneous guesses the way they can with sha-256. Combined with a unique cryptographic salt per hash, password salting ensures that precomputed rainbow table attacks and dictionary attacks against multiple accounts simultaneously are defeated. The salt generation is automatic, cryptographically secure, and embedded in the encoded string — you never need to manage it separately. Adding a pepper (a site-wide server secret stored outside the database) via pepper management further hardens login data against a database-only breach, though pepper requires careful secret management like other sensitive settings.

Argon2 Implementation Examples by Language — PHP, Node.js, Python, and Java

Every major language ecosystem provides a well-maintained, trusted argon2id library. The following examples demonstrate the minimum viable pattern for secure login hashing and hash verification. Always use these trusted libraries rather than rolling your own implementation.

PHP — password_hash and password_verify (Argon2id)

Argon2 PHP support is built into PHP 7.3+ via the password_hash and password_verify functions. No additional dependency is required:

<?php
// Built into PHP 7.3+ — no composer dependency required
// Confirm Argon2 support: php -r "echo defined('PASSWORD_ARGON2ID') ? 'ok' : 'missing';"

<?php
$password = 'CorrectHorseBatteryStaple';

// Hash using PASSWORD_ARGON2ID constant
$hash = password_hash($password, PASSWORD_ARGON2ID, [
    'memory_cost' => 65536, // 64 MB in KB
    'time_cost'   => 3,
    'threads'     => 4,
]);

echo $hash;
// $argon2id$v=19$m=65536,t=3,p=4$...$...

// Verify — password_verify extracts parameters from the saved hash automatically
if (password_verify($password, $hash)) {
    echo 'Password valid — login successful.';
} else {
    echo 'Invalid password.';
}

Node.js — argon2 npm Package with Async/Await

Argon2 Node.js support is provided by the argon2 npm package — a native binding to the reference C implementation. This is the canonical JavaScript server-side argon2 library.

npm install argon2

const argon2 = require('argon2');

async function hashPassword(password) {
  return argon2.hash(password, {
    type: argon2.argon2id,      // argon2id type
    memoryCost: 65536,          // memoryCost in KB (64 MiB)
    timeCost: 3,                // timeCost (iterations)
    parallelism: 4,             // parallelism threads
    hashLength: 32,             // hashLength in bytes
    saltLength: 16,             // saltLength in bytes
  });
}

async function verifyPassword(storedHash, password) {
  const isValid = await argon2.verify(storedHash, password);
  return isValid;
}

(async () => {
  const password = 'CorrectHorseBatteryStaple';

  const hash = await hashPassword(password);
  console.log('Encoded hash:', hash);
  // $argon2id$v=19$m=65536,t=3,p=4$...$...

  const valid = await verifyPassword(hash, password);
  console.log('Password valid?', valid); // true
})();

Python — argon2-cffi Python Binding

Argon2-cffi is the standard Python binding to the Argon2 reference implementation. It wraps the C library via CFFI and exposes a high-level PasswordHasher API. Install via:

pip install argon2-cffi

from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

# Instantiate with production-grade parameters
ph = PasswordHasher(
    time_cost=3,       # iterations
    memory_cost=65536, # 64 MiB in KB
    parallelism=4,
    hash_len=32,       # output length in bytes
    salt_len=16,       # 16-byte random salt
)

password = 'CorrectHorseBatteryStaple'

# Hash — salt is auto-generated
hash = ph.hash(password)
print(hash)
# $argon2id$v=19$m=65536,t=3,p=4$...$...

# Verify — raises VerifyMismatchError on failure
try:
    ph.verify(hash, password)
    print('Password valid.')
except VerifyMismatchError:
    print('Invalid password.')

Java — de.mkammerer.argon2 Java Binding

Argon2 Java support is available through the de.mkammerer.argon2 Maven dependency — a JVM binding to the native Argon2 library.

<dependency>
  <groupId>de.mkammerer</groupId>
  <artifactId>argon2-jvm</artifactId>
  <version>2.11</version>
</dependency>

import de.mkammerer.argon2.Argon2;
import de.mkammerer.argon2.Argon2Factory;

public class Argon2Example {
    public static void main(String[] args) {
        Argon2 argon2 = Argon2Factory.create(Argon2Factory.Argon2Types.ARGON2id);

        char[] password = "CorrectHorseBatteryStaple".toCharArray();

        // Hash: iterations=3, memory=65536 KB, parallelism=4
        String hash = argon2.hash(3, 65536, 4, password);
        System.out.println(hash);

        // Verify
        if (argon2.verify(hash, password)) {
            System.out.println("Password valid.");
        } else {
            System.out.println("Invalid password.");
        }

        // Wipe password from memory
        argon2.wipeArray(password);
    }
}