Bcrypt Generator
Generate and verify bcrypt hashes in your browser with configurable cost.
Argon2 Generator
Generate Argon2 password hashes and verify passwords against existing hashes — entirely in your browser via a vendored WebAssembly build of the reference library. Configure the variant (Argon2id is the modern default), memory cost, iterations, and parallelism. Nothing is sent to a server. Useful for testing authentication code that uses Argon2, generating seed data for migrations, and confirming a stored hash matches a typed password.
Generate an Argon2 Hash
Verify a Password Against an Argon2 Hash
How to Use This Tool
- Choose hash or verify — hash to generate a new Argon2 hash from a password, verify to check whether a password matches an existing hash.
- Pick the variant — Argon2id is the modern default and what almost every production system should use. Argon2i and Argon2d are exposed for testing.
- Set the cost parameters — memory (KB), iterations (time), parallelism. OWASP 2023 baseline is m=19456, t=2, p=1. Raise for stronger hashing at the cost of more compute time.
- Type the password and generate — a fresh random salt is generated for every hash. The output is a complete PHC-format string you can store directly.
- Copy or verify — the encoded hash is ready to paste into your database or test against a candidate password via the verify section.
How Argon2 Works
Argon2 is a memory-hard password hashing function — it deliberately allocates and reads back a large block of memory (typically 19 to 64 MiB or more) during each hash computation. This is the property that makes it stronger than bcrypt against attackers with GPUs or custom hardware: a GPU has thousands of cores but very limited per-core memory, so running tens of thousands of Argon2 hashes in parallel doesn't fit. The attacker is forced to use external RAM, which throttles the parallel rate by orders of magnitude compared to bcrypt or SHA-based hashes.
Three parameters tune the algorithm. Memory cost (m) sets how many kibibytes of RAM each hash uses; higher means more attack resistance but slower. Time cost (t) controls the number of passes over the memory; doubling roughly doubles the time. Parallelism (p) splits the work across threads — useful for matching your production server's available cores. All three combine to determine total work per hash; tune them to hit a target latency (250-500ms is typical) on your real server.
Argon2id, the recommended variant, is a hybrid: it runs Argon2i (data-independent access, side-channel safe) for the first half of the computation, then switches to Argon2d (data-dependent, faster) for the rest. This gives most of the side-channel resistance of pure Argon2i with most of the speed of Argon2d. Unless you're hashing in an environment with known side-channel risk (shared hosting, suspect VMs) or specifically need maximum speed, Argon2id is the right choice.
Frequently Asked Questions
What is Argon2 and why is it recommended over bcrypt?
Argon2 is the password hashing function that won the Password Hashing Competition in 2015. Its key innovation over bcrypt is memory-hardness — each hash computation requires a tunable amount of RAM (typically 64MB to 1GB), which makes attacks using GPUs and custom ASICs dramatically more expensive than against bcrypt. Bcrypt only spans roughly 4KB of state per hash, which is the exact size that fits comfortably on a modern GPU's shared memory; Argon2 with 64MB of memory cost forces the attacker to use external RAM, throttling the parallel attack rate by orders of magnitude. Bcrypt is still safe; Argon2id is just better against well-funded attackers.
What is the difference between Argon2d, Argon2i, and Argon2id?
Argon2d uses data-dependent memory access — fastest, but vulnerable to side-channel timing attacks. Suitable for cryptocurrency proof-of-work where side-channel attacks aren't a concern. Argon2i uses data-independent memory access — slightly slower, immune to side channels, suitable for password hashing in environments where timing might leak. Argon2id is a hybrid that runs Argon2i for the first pass and Argon2d for the rest — gets most of both benefits and is the recommended default for password hashing. OWASP, the PHC team, and every modern library recommend Argon2id unless you have a specific reason to pick one of the others.
What parameters should I use for Argon2id in production?
OWASP's 2023 recommendation is the baseline:
m=19456 (19 MiB memory), t=2 (iterations), p=1 (parallelism). For higher-security applications: m=65536 (64 MiB), t=3, p=4. The latency target most teams aim for is 250-500ms per hash on the production server — slow enough to throttle brute-force attacks, fast enough that login latency is invisible. Use the speed test on this page to find the highest cost factor your server can sustain without affecting user experience. As hardware gets faster, raise the parameters during the next planned re-hash cycle.What does an Argon2 encoded hash look like?
Argon2 outputs in the PHC string format, the same convention bcrypt uses. A typical Argon2id hash looks like
$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG. The fields are: algorithm variant (argon2id), version (v=19), parameters (m=memory,t=iterations,p=parallelism), the salt (base64), and the hash itself (base64). The whole string goes into a single database column — verification re-extracts the parameters and salt, so there's nothing to store separately.Why does this tool take longer than the bcrypt generator with similar settings?
Two reasons. First, Argon2 with 64 MiB of memory cost is genuinely doing more work than bcrypt at cost 12 — it has to allocate, fill, and read back tens of megabytes of memory in addition to the compute cost, which is the whole point of memory-hardness. Second, this tool runs Argon2 in WebAssembly inside a single browser thread, while a real server typically uses native code with optimized memory access patterns and runs hashes in parallel across multiple cores. Treat the timings here as relative — the ratio between different parameter settings is meaningful, but the absolute numbers are slower than what your production server will see.