When you create an account on a website, you usually type your password once and never think about it again. The next time you log in, you enter the same password and everything works as expected.

It’s easy to assume that somewhere on the server there’s a database containing your username next to your password. After all, how else would the website know whether you’ve entered the correct one?

The surprising answer is that, on a well-designed system, your password is never stored in a form that anyone can read, not even the company that owns the website.

Your password is transformed, not stored

Instead of saving your password directly, the server runs it through something called a hash function. You can think of a hash as a digital fingerprint. It always produces the same output for the same password, but it’s designed to work in only one direction.

For example, if we take the password:

myPassword123

and hash it, we get something that looks like this:

a336f671080fb420c27461fcf4f2c8d1d87b8a5f6d6f8b5f8f13c2b7d5ad7168

That long string of seemingly random characters is what gets stored in the database, not your actual password. Modern applications typically use dedicated password hashing algorithms such as bcrypt or Argon2, but the basic idea is the same: the password is transformed into a value that can’t realistically be reversed.

The next time you log in, the server hashes the password you entered again and compares the new hash with the one stored in the database. If they match, you entered the correct password, even though the server never needed to know what your password actually was.

Then how does password reset work?

This was the question that confused me the first time I learned about password hashing.

If a website doesn’t actually know my password anymore, how can it send it back to me when I click Forgot Password?

The answer is that it can’t.

A properly designed system never emails your existing password because it doesn’t have access to it. Instead, it generates a temporary, time-limited token that proves you requested a password reset. After you choose a new password, the old hash is discarded and replaced with a new one.

That’s also why receiving your original password in an email should immediately raise a red flag. It usually means the website stored it in plain text or used an insecure method to protect it.

Good security is often about storing less

One of the things I enjoy most about software engineering is discovering ideas that seem counterintuitive at first.

Most people assume security is about building stronger walls around sensitive information. While that’s certainly part of it, an even better approach is to avoid storing information you don’t actually need.

A website doesn’t need to know your password after you’ve signed up. It only needs a reliable way to verify that the password you enter later is the same one you originally chose.

That small design decision dramatically reduces the damage a data breach can cause. Even if someone steals the database, they won’t find a list of everyone’s passwords waiting for them.

Sometimes the smartest engineering decision isn’t protecting more data—it’s making sure you never keep it in the first place.