What Is Hashing? — Flassword guide

What Is Hashing? A Beginner's Guide to Password Hashing

By the Flassword Team · ⏱️ Reading time: 8 min · 🟡 Intermediate · Last updated July 12, 2026

Every time you type a password into a site that was actually built with care, that password is put through a one-way mathematical function called a hash before it's ever stored. Understanding what that means — and why some hashing choices are dramatically safer than others — explains a lot about why some data breaches are catastrophic and others are barely a footnote.

What is a hash function?

A hash function takes any input — a word, a file, an entire book — and produces a fixed-length string of characters called a hash, or digest. The same input always produces the same hash, but the process only runs one way: there's no operation that takes a hash and calculates the original input back out of it directly.

Two properties make hash functions useful for security. First, the avalanche effect: changing even one character of the input completely scrambles the output, so similar inputs never produce similar-looking hashes. Second, collision resistance: for a good hash function, finding two different inputs that produce the same output should be computationally infeasible. Together, these make a hash a reliable fingerprint for whatever went in.

How password hashing works

When you create an account on a well-built site, your password is never saved as typed. Instead, the server runs it through a hash function and stores only the resulting digest. When you log in later, the site hashes whatever you typed and compares that new hash to the stored one — if they match, the password was correct, even though the server never kept a copy of the actual password to compare against.

This is precisely what limits the damage in a well-handled breach. If attackers steal a database of properly hashed passwords, they don't get a list of everyone's actual password — they get a list of digests they still have to work to reverse, one guess at a time, exactly the process our how hackers crack passwords guide covers in more depth.

Hashing vs. encryption vs. encoding

These three terms get mixed up constantly, and the differences matter:

  • Hashing is one-way. There's no key, and no legitimate way to reverse it — only guessing.
  • Encryption is two-way and uses a key. Whoever holds the right key can decrypt the data back to its original form, which is exactly why encryption — not hashing — is used for data you need to read again later.
  • Encoding isn't security at all. It's a reversible format conversion with no key and no secrecy involved — see our Base64 encoding explained guide for a common example that's frequently, and wrongly, assumed to be secure.

Passwords should always be hashed, never just encrypted and never just encoded. A site that "decrypts" your password to email it back to you in plain text is telling you it never hashed it properly in the first place.

Salting, and why it matters

A salt is a random value generated for each user and combined with their password before hashing. Without one, every account sharing the same password gets an identical hash, and an attacker can precompute a giant lookup table of common passwords and their hashes once, then check it against an entire stolen database instantly — a shortcut called a rainbow table attack.

Salting closes that shortcut entirely. Even two users with the identical password "correcthorse123" end up with two completely different stored hashes, and an attacker has to attack each one individually rather than reusing precomputed work across the whole database. Every modern password hashing algorithm handles salting automatically.

Modern password hashing algorithms compared

Not every hash function belongs in the same conversation. General-purpose hashes like SHA-256 are built for speed, which is exactly the wrong property for password storage — the faster a hash runs, the faster an attacker can test guesses against it. Purpose-built password hashing algorithms are deliberately slow and tunable instead.

Algorithm Built for password storage? Why
MD5 / SHA-1 No Fast, and both have known cryptographic weaknesses. Fine for checksums, never for passwords.
SHA-256 / SHA-512 No Cryptographically strong but deliberately fast — billions of guesses per second are feasible on stolen hashes.
PBKDF2 Yes, with high iteration counts Repeats a standard hash thousands of times to slow it down. Widely supported, though newer options resist specialized hardware better.
bcrypt Yes Purpose-built for passwords, with a tunable work factor. A long-standing, well-trusted default.
scrypt / Argon2 Yes Also memory-intensive, not just slow, which makes large-scale cracking hardware far more expensive to build. Argon2 won the 2015 Password Hashing Competition and is the current recommended default.

To put the difference in real terms: an 8-character password drawn from a full 90-character set has about 4.3 quadrillion possible combinations. Hashed with a fast, unsalted algorithm at a billion guesses a second, that falls in roughly 25 days on average. Hashed with bcrypt-style slowness limiting an attacker to around 10 guesses a second, the same password would take on the order of millions of years. The password didn't change — the hashing choice did all the work.

See hashing in action

You can watch the avalanche effect for yourself with our Hash Generator: type any word, note the SHA-256 output, then change a single character and watch the entire hash change completely. It's a good way to build real intuition for why hashes make reliable fingerprints — and why none of the algorithms it demonstrates (MD5 through SHA-512) should ever be used to store a password directly, since all of them are general-purpose and fast by design, unlike bcrypt or Argon2.

Tip: As a user, you can't control which hashing algorithm a site uses for your password — but you can control how much that choice matters. A long, unique, randomly generated password stays hard to guess even against a fast, poorly-chosen hash, buying you time to change it after a breach notification.

Frequently asked questions

Can a hash be reversed back into the original password?

Not directly. A well-designed hash function is one-way by construction — there's no mathematical shortcut back to the input. The only practical way to "reverse" one is to guess inputs and hash each guess until one matches, which is exactly what a slow, adaptive hashing algorithm is built to make painfully expensive.

What is salting, and why does it matter?

A salt is a random value added to each password before hashing, unique per user. Without salts, two people with the same password get the same hash, and an attacker can precompute hash tables for common passwords once and reuse them against every account. Salting forces a fresh computation for every single password, every time.

Is SHA-256 good enough for hashing passwords?

No, even though it's a strong, modern algorithm in general. SHA-256 is deliberately fast, which is perfect for verifying file integrity but terrible for password storage — a fast hash lets an attacker test billions of guesses per second on stolen data. Password storage needs a slow, adaptive algorithm built specifically for that job.

Does hashing mean a breach can't expose my password?

It means your exact password isn't sitting in the stolen file in plain text, but it doesn't guarantee safety. If the service used a weak or unsalted hash, or your password was short and guessable, an attacker can often recover it anyway. Assume any password from a breached service should be changed, hashed or not.

Can I check what a hash algorithm actually produces?

Yes — our Hash Generator computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512 from any text you type, entirely in your browser, so you can see exactly how the same input produces a completely different-looking output under each algorithm.

Why do two very similar passwords produce completely different hashes?

This is called the avalanche effect, and it's a deliberate design goal of every cryptographic hash function. Changing even a single character in the input should flip roughly half the bits in the output, so similar inputs never produce similar-looking hashes that could hint at the original value.

Conclusion

Hashing is the reason a data breach doesn't automatically mean every password is instantly readable — but only when it's done with an algorithm built for the job. MD5, SHA-1, and even SHA-256 are the wrong tool for password storage despite being excellent hash functions in general; bcrypt, scrypt, and Argon2 exist specifically to make guessing slow and expensive. As a user, you can't pick the algorithm, but a long, random, unique password keeps you protected either way.

Related articles

Free tools for this guide