Password Hash Generator

Generate secure password hashes and verify them using industry-standard algorithms

Enter a password and click "Generate Hash"
Enter a password and hash to verify

Password Hashing Best Practices

Why proper password storage matters for security

Always Use a Salt

Salting adds random data to passwords before hashing, preventing rainbow table attacks and ensuring identical passwords produce different hashes.

Use Key Stretching

Algorithms like PBKDF2, bcrypt, and Argon2 apply multiple iterations to slow down brute-force attacks, making password cracking computationally expensive.

Avoid Plain SHA

Plain SHA-256/512 hashes are fast to compute, making them vulnerable to brute-force attacks. Always prefer PBKDF2, bcrypt, or Argon2 for password storage.

Hashing passwords correctly

Why general-purpose hashes are wrong

SHA-256 and MD5 are designed to be fast, which is exactly the wrong property here. A modern GPU computes billions of SHA-256 hashes per second, so a leaked database of SHA-256 password hashes is cracked at enormous scale.

Password hashing functions are deliberately slow and memory-hard. Argon2id is the current recommendation, with bcrypt and scrypt as well-established alternatives. All three let you tune a work factor upward as hardware improves.

Salt and pepper

A salt is a unique random value per password, stored alongside the hash. It stops one precomputed rainbow table from attacking every account at once, and stops two users with the same password producing identical hashes. Modern algorithms generate and embed the salt for you.

A pepper is a secret value applied to every password, stored separately from the database — in an HSM or secrets manager. If the database leaks but the pepper doesn't, the hashes are unattackable. It's an extra layer, not a substitute for a proper algorithm.

Or don't store passwords at all

Every consideration here exists because you're holding a shared secret. Passkeys remove that: the server stores a public key, and a breach yields nothing worth stealing.

Where passwords must remain, the surrounding controls matter as much as the hash — rate limiting, breach-corpus checks on new passwords, and a reset flow that isn't itself the weakest link.

Frequently asked questions

Argon2id if your platform has a well-maintained implementation. bcrypt remains a solid, widely-available choice. scrypt is fine. Never use MD5, SHA-1, or a bare SHA-256 for passwords — speed is a liability here, not a feature.

No. Hashing runs entirely in your browser. Even so, use test values rather than real credentials in any web-based tool as a matter of habit.

Tune it to your hardware: aim for roughly 200 to 500 milliseconds per hash on your production machines. That's slow enough to make offline cracking expensive and fast enough not to hurt login. Revisit it periodically as hardware improves.

bcrypt generates a random salt and embeds it in the output string, so you don't manage it separately. What you must not do is reuse a fixed salt across users, which defeats the purpose entirely.

Generally no. Client-side hashing makes the hash the credential, so an attacker who intercepts it can replay it. Send the password over TLS and hash server-side. Client hashing only makes sense as an additional layer, never as a replacement.

Next steps

Related tools

In the docs

All developer tools

Don't store passwords at all

Hashing correctly is the easy half. Breach detection, rotation policy, brute-force protection, and reset flows are the rest — or skip passwords entirely with passkeys.

Start free Read about user management

Free, unlimited users. No credit card required.