A hash function takes an input, any input, and produces a fixed-length string of characters called a hash or digest. Feed it the word "hello" and it spits out something like 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Feed it a 500-page novel and you get a string of the same length. That consistency, combined with a set of mathematical guarantees, makes hash functions one of the most useful tools in all of computing.
You've already relied on one today. When you logged into a website, the server didn't compare your password to a stored copy of your password. It ran your input through a hash function, then compared the result to a stored hash. Your actual password never sat in a database. That's hashing at work.
What makes a good hash function?
Not all hash functions are the same. Security-grade hashing carries four properties that cheap or broken alternatives don't reliably offer.
First: determinism. The same input must always produce the same output. Without that, you can't verify anything. Second: speed, but not too much of it. A password-hashing function should be fast enough to respond in milliseconds but slow enough that an attacker can't try billions of guesses per second. Third: the avalanche effect. Change a single character in the input and the entire output changes completely. "hello" and "hellp" produce hashes that look nothing alike. Fourth: irreversibility. You can't work backwards from the hash to the original input. That's the point.
A fifth property applies to cryptographic uses: collision resistance. A collision is when two different inputs produce the same hash. A good function makes collisions computationally impossible to find on purpose, even though they technically exist (infinitely many inputs, finite output space).
Common hash algorithms in use today
The algorithm family you'll encounter most is SHA-2, which includes SHA-256 and SHA-512. SHA-256 produces a 256-bit hash and is used in Bitcoin's proof-of-work system, in TLS certificates, and in software verification. SHA-512 outputs 512 bits and shows up where extra margin is needed.
MD5 and SHA-1 are older and now considered broken for security purposes, collisions have been deliberately produced against both. MD5 still appears in non-security contexts like checksums for file integrity checks, where the threat model doesn't involve a motivated attacker.
For passwords specifically, bcrypt, scrypt, and Argon2 are the modern choices. These are deliberately slow and memory-intensive, which makes brute-force cracking expensive. Argon2 won the Password Hashing Competition in 2015 and remains the recommended choice. A fast general-purpose hash like SHA-256 is the wrong tool for passwords, precisely because fast is bad when your job is to resist guessing attacks.
How hashing protects your passwords
When you create a password on a site, the server runs it through a hashing algorithm and stores only the result. When you log in, it hashes what you typed and compares the two hashes. If they match, you're in.
A well-built system also adds a salt: a random string appended to your password before hashing. Without a salt, an attacker who gets hold of a database can use a precomputed table of common password hashes (called a rainbow table) to crack many accounts at once. The salt ensures that even if two users pick the same password, their hashes are different. Each account's hash is only crackable with its own brute-force attempt.
This is directly related to broader account security. Understanding two-factor authentication and how it works adds another layer on top of this; even if an attacker somehow recovers your password hash and cracks it, a second factor stops them from getting in.
Hashing beyond passwords
Password storage is one use. The others are just as important.
File integrity checking is straightforward. When you download software, the developer publishes the SHA-256 hash of the installer. You hash the file you downloaded and compare. If they match, the file wasn't tampered with in transit. This is how Linux distributions have distributed ISOs for years.
Digital signatures rely on hashing too. Rather than encrypting an entire document (slow and unwieldy), the signer hashes it and encrypts only the hash. The recipient decrypts the hash, re-hashes the document, and compares. This is central to the way public key infrastructure binds identities to cryptographic keys.
Hash tables are a data structure in software development that uses hashing for fast lookups. Your programming language's dictionary or map type almost certainly uses one. The hash of a key determines where in memory the value lives, making retrieval nearly instant regardless of how large the collection is.
Blockchain systems chain blocks of transaction data together by including the hash of the previous block in each new one. Altering a historical block changes its hash, which breaks the chain, which signals tampering. The hash is what makes the ledger tamper-evident.
What hashing cannot do
Hashing is one-way. It is not encryption. Encryption is reversible if you hold the key; hashing is not reversible at all. You cannot "decrypt" a hash to get the original input back. If a developer tells you they'll "decrypt" your forgotten password, they've stored it insecurely. A properly built system has no way to recover your original password. It can only reset it.
Hashing also doesn't protect against weak inputs. A strong algorithm won't save a user who picks "password123". The hash of a predictable input is still crackable by trying common inputs against it. That's why password policies and breach notifications matter alongside the technical safeguards.
A hash function guarantees the integrity of data. It says nothing about the authenticity of who sent it. For that, you need a digital signature built on top of the hash, which brings in asymmetric cryptography. The two tools work together, not in place of each other.
Recognising hashing in the real world
Next time a site tells you it "cannot recover" your password, that's a sign they've done it right. When a software download page lists a SHA-256 checksum, that's hashing for file verification. When Git identifies a commit by a 40-character string, that's a SHA-1 hash of the commit contents (Git is in the process of migrating to SHA-256 for new repositories).
Hashing is invisible infrastructure. It runs constantly, on servers and in browsers, without requiring any action from the people it protects. Understanding what it does makes it easier to spot when something has gone wrong, like a site that emails you your password in plain text, which means it never hashed it in the first place.