Password Hashing Explained: How Sites Store Your Password Safely
Password hashing is the process of converting a password into a fixed, scrambled string using a one-way function, so a website can verify your login without ever storing your actual password. Unlike encryption, hashing can't be reversed—there's no key to turn the hash back into the original. That's the whole point: even if a site's database is stolen, well-hashed passwords are extremely hard to recover. The catch is that how you hash matters enormously, and getting it wrong is the same as storing passwords in plain text.
This guide explains how hashing works, why fast algorithms like MD5 and SHA-256 are the wrong choice for passwords, what salting and memory-hardness mean, and which algorithm to actually use in 2026. It's written for developers and the security-curious alike.
Hashing vs. encryption (they're not the same)
People mix these up constantly. Encryption is two-way: data is scrambled with a key and can be unscrambled with that key. Hashing is one-way: it transforms input into a fixed-length output that cannot be reversed back into the original. When you log in, the server hashes the password you typed and compares it to the stored hash—if they match, you're in. The server never needs (or keeps) your real password. You can watch a hash get generated with our MD5 Generator—just don't use MD5 for real passwords, for reasons we'll get to.
Why you can't just store passwords
If a site stores passwords as plain text and gets breached, every account is instantly compromised—and because people reuse passwords, the damage spreads to other services through credential-stuffing attacks. Hashing is the defense: store the hash, not the password. But not all hashing is equal, and this is where most mistakes happen.
Why fast hashes (MD5, SHA-256) are wrong for passwords
Here's the counterintuitive part: for passwords, speed is bad. Algorithms like MD5, SHA-1, and SHA-256 were designed to be fast—great for verifying file integrity, terrible for passwords. A modern GPU can compute on the order of 10–22 billion SHA-256 hashes per second, which means an attacker who steals a SHA-256 database can test an entire common-password wordlist almost instantly. If you're hashing passwords with MD5 or SHA-256, your users' passwords are effectively stored in plain text. The fix is an algorithm that's deliberately slow.
The three properties a password hash needs
A proper password hashing function has three traits that general-purpose hashes lack:
Deliberate slowness. A tunable "work factor" makes each hash take a meaningful fraction of a second—negligible for one login, but crippling for an attacker trying billions of guesses. Per-record salt. A unique random value added to each password before hashing, so two users with the same password get different hashes. Salt defeats precomputed "rainbow table" attacks and stops attackers from cracking many accounts at once. Memory-hardness. The best modern algorithms also demand significant memory per hash, which neutralizes the parallel-cracking advantage of GPUs and specialized hardware.
Note what salt does and doesn't do: it prevents rainbow tables and identical hashes, but it doesn't slow down a brute-force attack—only a deliberately slow algorithm does that. The two work together.
A note on salt and pepper
Modern algorithms generate and embed the salt automatically inside the hash output, so you don't store it separately. Some systems add a pepper—a secret value kept outside the database (in an environment variable or secrets manager)—as an extra layer, so a leaked database alone isn't enough to start cracking. Salt is per-user and stored with the hash; pepper is global and kept secret.
Which algorithm to use in 2026
Four algorithms dominate the conversation. Here's the practical guidance, aligned with the OWASP Password Storage recommendations:
Argon2id — the default choice for new projects. It won the Password Hashing Competition, is standardized in RFC 9106, and is both memory-hard and GPU-resistant. OWASP's baseline parameters are roughly m = 19 MiB, t = 2, p = 1 (tune upward to your hardware). bcrypt — still cryptographically sound at a cost factor of 12 or higher, and fine to keep on existing systems; its limitations are a 72-byte input cap and a fixed, smaller memory footprint that makes it less GPU-resistant than Argon2. scrypt — memory-hard and solid, but largely superseded by Argon2 for new work. PBKDF2-SHA256 — the FIPS-compliant option when regulations require it, at a minimum of around 600,000 iterations. The one rule everyone agrees on: never use MD5, SHA-1, or plain SHA-256/512 for passwords.
If you're building on WordPress and want to see how a platform generates a stored password hash, our WordPress Password Hash Generator demonstrates the format WordPress uses.
Migrating without forcing a password reset
If you're on a weak algorithm, you don't have to reset everyone's password. The standard approach is to rehash on login: when a user authenticates successfully, check whether their stored hash uses an outdated algorithm or cost factor, and if so, re-hash the password they just supplied with the stronger settings. Over time, active accounts upgrade transparently. Prioritize by urgency—plain text, MD5, and SHA-1 demand immediate migration; weak SHA-256 or low-iteration PBKDF2 should be addressed soon. The switch is entirely server-side and invisible to users, who simply keep logging in over HTTPS as normal.
What this means for you as a user
You can't control how a website hashes your password, but you can make hashing work in your favor: use a long, unique password for every account so that even if a site's hashed database leaks, yours is impractical to crack and useless elsewhere. That's exactly the approach in our guide to creating a strong password—generate long random passwords with our Password Generator and test them with the Password Strength Checker.
Frequently asked questions
Is hashing the same as encryption?
No. Encryption is reversible with a key, so encrypted data can be decrypted. Hashing is one-way—you can't turn a hash back into the original password. That's why hashing is used for password storage: the site can verify a password by re-hashing it and comparing, without ever being able to recover the original.
Why is MD5 bad for passwords?
MD5 is fast and has known cryptographic weaknesses, so attackers can compute billions of guesses per second and crack hashed passwords almost instantly. It's fine as a checksum for non-security tasks, but using it for passwords is effectively the same as storing them in plain text. Use Argon2id or bcrypt instead.
What is a salt, and why does it matter?
A salt is a unique random value added to each password before hashing, so identical passwords produce different hashes. It prevents precomputed rainbow-table attacks and stops an attacker from cracking many accounts at once. Modern algorithms generate and store the salt automatically inside the hash.
Which password hashing algorithm should I use in 2026?
For new projects, use Argon2id—it's the OWASP recommendation, memory-hard, and GPU-resistant. bcrypt at cost 12+ remains acceptable, especially on existing systems, and PBKDF2-SHA256 is the choice when FIPS compliance is required. Avoid MD5, SHA-1, and plain SHA-256 for passwords entirely.
Final thoughts
Password hashing is a small piece of code with outsized consequences. Done right—a slow, salted, memory-hard algorithm like Argon2id—it means a stolen database is a headache rather than a catastrophe. Done wrong, with a fast hash like MD5, it offers almost no protection at all. Whether you build systems or just use them, the principle is the same: strong hashing on the server and strong, unique passwords on your side are what keep a breach from becoming a disaster.