A hash turns any input — a word, a file, a whole database — into a short fixed-length string of characters. The same input always produces the same hash, and even a one-character change produces a completely different result. That simple property makes hashes useful for a surprising range of everyday tasks: checking that a downloaded file arrived intact, comparing two files without opening them, and storing passwords safely. But hashes are also widely misunderstood, and using the wrong kind for the wrong job can range from harmless to genuinely dangerous.
This guide explains what a hash actually is, the practical difference between the common algorithms, and — most importantly — which situations each one is right for.
A hash is a one-way fingerprint
The key idea is that hashing only goes one way. You can turn a file into its hash instantly, but you cannot turn the hash back into the file — the original information is not stored in it. That is deliberate. A hash is a fingerprint: small, fixed in size, and unique enough that two different inputs almost never share one. A 4 KB document and a 4 GB video both produce a hash of the same length.
Because the output is fixed-length and the input can be anything, infinitely many possible inputs map to each possible hash. In practice, for a good algorithm, finding two inputs that collide is so hard that we treat each hash as effectively unique to its input.
Why one changed character changes everything
A well-designed hash has the avalanche property: flip a single bit of the input and roughly half the output bits change. This is what makes hashes useful for integrity checking. If you hash a file before sending it and hash it again after it arrives, a matching result means the file is byte-for-byte identical. A single corrupted byte during download produces a completely different hash, so the mismatch is obvious even though the corruption might be invisible if you just opened the file.
MD5 and SHA-1: fine for accidents, not for attackers
MD5 and SHA-1 are older algorithms that are now considered broken for security purposes, because researchers have found ways to deliberately construct two different inputs with the same hash. That matters enormously if an attacker is trying to fool you — they could craft a malicious file with the same MD5 as a legitimate one.
But for detecting accidental change, they are still perfectly serviceable and fast. Using MD5 to check whether a file copied correctly, or to spot duplicate files, is fine, because a random copying error will not happen to produce a matching hash. The rule of thumb: MD5 and SHA-1 are acceptable against accidents, never against adversaries.
SHA-256 is the safe modern default
When the hash needs to resist deliberate tampering — verifying a software download, signing data, anything security-related — use SHA-256 (part of the SHA-2 family) or stronger. No practical collision attack is known against it, it is widely supported, and it is what most software publishers list next to their downloads. If you are unsure which algorithm to pick, SHA-256 is the answer that is almost never wrong.
Verifying a download, step by step
This is the most common real use. A project publishes its installer along with a SHA-256 value (sometimes in a file called SHASUMS or shown on the download page). After downloading, you generate the SHA-256 of your copy and compare it to the published one, character by character or with a quick copy-paste comparison.
If they match, your file is exactly what the publisher released — not corrupted in transit and not swapped for a tampered version. If they differ, do not run the file. Re-download it and check again; a persistent mismatch means something is wrong with the source or the transfer.
Hashing passwords is a different job
Storing passwords is a special case where the plain hash algorithms above are the wrong tool. Fast hashes like SHA-256 are a liability here precisely because they are fast: an attacker who steals a database of SHA-256 password hashes can try billions of guesses per second. Password storage uses deliberately slow, salted algorithms designed for the purpose — such as bcrypt, scrypt, or Argon2 — which add a unique random salt to each password and are tuned to be expensive to compute.
If you are building something that stores passwords, do not hash them with MD5 or SHA-256 and call it done. Use a purpose-built password-hashing function. For your own passwords, the practical takeaway is simpler: length and uniqueness matter more than which hash a service uses behind the scenes.
What a hash cannot do
A hash is not encryption. Encryption is reversible with a key; a hash is not reversible at all, which means you cannot use it to hide a message you later want to read back. A hash also does not, by itself, prove who created something — for that you need a signature, which combines a hash with a private key. And a short input like a common password can sometimes be found by simply hashing every likely candidate and looking for a match, which is why salting and slow algorithms exist. Knowing these boundaries keeps you from reaching for a hash where a different tool is required.
Tools used in this workflow
Primary tool: Hash Generator →
Related: Password Generator