Password Hash Generator and Verifier
(Argon2id, bcrypt, scrypt, PBKDF2 — 2026 OWASP defaults)
Client-side tool to generate and verify password hashes with realistic, up-to-date parameters. Helpful for debugging integrations and for understanding how salts, memory, and iterations affect cost. Defaults follow the OWASP 2026 baseline (Argon2id m = 19 MiB, t = 2, p = 1) and NIST SP 800-63B PBKDF2 minimums. Runs locally — no passwords leave your browser.
Your data security is our top priority. All hashing and verification happen in this browser. This tool does not store or send your password nor hashes outside of the browser.
Supported Password Hashing Functions
Argon2id Generator & Parameters (2026 settings)
Argon2id is a modern, memory-hard function that raises the attacker's cost on GPUs and ASICs. The OWASP 2026 baseline is m = 19 MiB, t = 2, p = 1 with a 16-byte random salt. If hardware allows, m = 64 MiB / t = 3 / p = 4 is stronger. Tune until a single verification lands around 250–500 ms on production.
bcrypt Generator (cost / rounds)
bcrypt is battle-tested and widely available. Cost factor 12 is the 2026 minimum; cost 13–14 is preferred for new systems. Costs above 14 noticeably affect login latency. We output the $2b$ format for broad compatibility. Note bcrypt only considers the first 72 bytes of input.
scrypt Generator (N, r, p)
scrypt adds memory-hardness. The 2026 baseline is N = 2^17, r = 8, p = 1 (~128 MiB per verification). For interactive logins on modest hardware, N = 2^15 with r = 8, p = 1 is acceptable; never use values below 2^14.
PBKDF2 Generator (SHA-256 / SHA-512)
PBKDF2 remains the compatibility / FIPS-compliant workhorse. NIST SP 800-63B (2024 update) requires at least 600,000 iterations for PBKDF2-HMAC-SHA256, or 210,000 for PBKDF2-HMAC-SHA512. Revisit yearly as hardware improves.
Salts (and Optional Pepper)
The tool generates cryptographically secure salts and lets you set length and encoding (Hex/Base64). Some deployments also add a pepper (site-wide server secret) that's not stored in the hash. Use peppers carefully and manage them like other secrets.
Read more:
Password hashing & salting explained • How to pick the right hashing function
Read more:
Password hashing & salting explained • How to pick the right hashing function
How to use the Password Hash Generator
Step 1.
Enter a password
- Open the Generate tab and type a demo password (avoid real credentials).
Step 2.
Select an algorithm
- For new systems, Argon2id is generally recommended.
Step 3.
Set parameters:
- Argon2id: Memory (MiB), Iterations (t), Parallelism (p).
- bcrypt: Cost (2^cost rounds).
- scrypt: N (power of two), r, p.
- PBKDF2: Iterations and digest (SHA-256/512).
Step 4.
Generate Password Hash
- Click Generate Password Hash. Copy the encoded string.
Step 5.
Verify Password Hash
- Switch to Verify Password Hash to test a password + encoded hash pair.
Ready to Supercharge Your Authentication?
Experience seamless, secure, and scalable identity management with Authgear.
Get Started for Free
Is it safe to use this with real passwords?
All hashing happens locally in your browser. For your own safety, avoid using production secrets in any online tool.
Which hashing function should I use?
For new systems, Argon2id is generally recommended. bcrypt and scrypt are widely deployed; PBKDF2 is a compatibility fallback. Always benchmark and choose parameters that meet your latency targets.
How long should hashing take?
Many teams target ~250–500ms in the authentication path. Pick the slowest settings that still keep UX smooth on your production hardware.
Why won't my framework verify the hash?
Common issues: whitespace/line endings, encoding mismatch (hex vs Base64), bcrypt prefix differences ($2a$ vs $2b$), or forgetting a pepper.
What salt length should I use?
16–32 bytes of random data is standard. The tool defaults to secure randomness and shows length and encoding.
Can I decrypt a password hash with this tool?
No — and no other tool can either. Argon2id, bcrypt, scrypt, and PBKDF2 are one-way hash functions, not encryption. There is no key that "reverses" them. The only way to recover a password from a hash is to guess candidate passwords, hash each one, and compare. That is what password-cracking attacks do, and modern memory-hard parameters are tuned to make it economically prohibitive at scale. To verify a known password against a stored hash, use the Verify tab.
Argon2id vs bcrypt vs scrypt: which should I pick in 2026?
Argon2id is the recommended default for new systems — it is the PHC password-hashing competition winner and is memory-hard against GPU and ASIC attacks. bcrypt is fine for existing deployments at cost ≥ 12, but it is not memory-hard and has a 72-byte input limit. scrypt is also memory-hard and well-studied; pick it only if your runtime lacks a maintained Argon2id library. Use PBKDF2 only when FIPS / NIST compliance requires it.
How do I migrate from bcrypt to Argon2id without forcing a password reset?
Use opportunistic rehashing. Continue verifying existing users with bcrypt; on a successful login, hash the plain-text password they just typed with Argon2id and update the stored credential. Track a per-user hash-version field so you know which algorithm to verify with. Within a few weeks of normal user activity most accounts migrate; you can force the rest with a password-reset prompt for inactive users.