What a hash actually proves

A hash is a fingerprint, not a container

Feed any amount of data into a hash function and you get back a fixed-length string. A single character, a 40 gigabyte disk image, and the complete works of Shakespeare all come out of SHA-256 as exactly 64 hexadecimal characters. Nothing about the original size survives, because nothing about the original survives at all.

The output is not a compressed copy. It is a summary so lossy that the input is unrecoverable, and that is the entire point. The function runs in one direction and there is no reverse gear built into it, no matter how much computing power you point at the problem.

The property that makes this useful is the avalanche effect. Change one bit of the input, flip a single pixel, correct one typo, and roughly half the output bits change. The two hashes will not look similar. They will look unrelated, which means "close enough" is not a state a hash can express. Two files either produce the same fingerprint or they do not.

Misconception one: hashing is encryption

This is the big one, and it usually shows up as somebody searching for a hash decoder. Encryption takes data and a key, scrambles the data, and lets anyone holding the key put it back exactly as it was. Hashing takes data and produces a fingerprint. There is no key, no ciphertext, and no undo.

So what are those "decrypt MD5" sites doing? They are running a lookup. Somebody has hashed billions of common words, leaked passwords and short strings, stored the results in a database, and searches it for your value. If your input was on the list, they return it. If it was not, they return nothing, because there is nothing to compute.

That distinction matters practically. If you hash a document and lose the original, the document is gone. If you need something you can retrieve later, you want encryption, or you want an encoding like Base64, which is neither encryption nor hashing but a reversible way of writing bytes as text. Encoding hides nothing from anyone.

There is one place the confusion becomes dangerous: password storage. Passwords are not stored in plain text and they are not encrypted either, they are hashed, which is why a service can check your login but cannot email you your old password. But a plain fast hash is the wrong tool there. Password storage needs a deliberately slow algorithm with a unique random salt per user, and SHA-256 is neither slow nor salted. Use a purpose-built password hashing function for that job and a general hash for everything else. If you just want to know whether a password is any good, a password strength checker answers a different and simpler question.

Misconception two: MD5 is broken, full stop

MD5 is broken, and the sentence needs its qualifier. What broke is collision resistance: researchers can now construct two different files that produce the same MD5 hash, cheaply, on ordinary hardware. SHA-1 fell the same way, with a practical collision demonstrated in 2017.

That is fatal for anything an adversary touches. Signatures, certificates, integrity checks on software an attacker would love to substitute: all of these depend on nobody being able to build a second file matching the first fingerprint. For those, MD5 and SHA-1 are finished, and no amount of "but it is fine for our use case" changes it.

What did not break is the ordinary detection of accidental change. A hard drive flipping a bit, a truncated download, a file transfer that dropped a packet: none of these are deliberately constructing a collision, and the odds of random corruption landing on a matching MD5 remain effectively zero. Comparing backup copies or spotting duplicates with an MD5 hash generator is still legitimate. It is faster than SHA-256 and, for that narrow job, just as reliable.

The same logic runs further down. CRC32 is not a cryptographic hash at all, only a 32-bit error-detecting code, and it is genuinely useful for exactly one thing: noticing that a file changed. Never treat it as evidence that a file was not tampered with.

Which algorithm, and how long is the output

Digest length is the first thing to recognise, because it tells you what you are looking at. A 32-character hex string is MD5. Forty characters is SHA-1. Sixty-four is SHA-256, and 128 is SHA-512. If a download page lists a 40-character checksum, you now know it was produced before somebody updated their release process.

The recommendation is uncomplicated. Use SHA-256 unless something outside your control dictates otherwise, and generate one with a SHA-256 hash generator. It is fast enough that you will not notice, secure against everything currently practical, and universally supported. SHA-512 is not meaningfully more secure for realistic threats, though it can be quicker on 64-bit hardware. Reach for a SHA-512 generator, a SHA-1 generator or MD5 only when a system you cannot change is asking for that specific format.

Misconception three: a matching checksum proves the file is safe

It proves one thing precisely: the file you hold is byte-for-byte identical to the file the publisher hashed. That is genuinely valuable and it is also narrower than most people assume.

Consider what happens if an attacker controls the download server. They replace the installer and they replace the checksum printed beside it. Your hash matches perfectly. You have verified that you downloaded exactly the file that was offered to you, which was the malicious one. The check confirmed transfer integrity and said nothing about intent.

A checksum is therefore only as trustworthy as its channel. Value it when the hash reaches you separately from the file: over a different domain, from a signed release announcement, from documentation you already trusted, or from a colleague who built the file themselves. When the checksum sits directly under the download button on the same page, it is a corruption check and nothing more. Useful, but do not mistake it for a security guarantee.

To actually verify a download, drop the file into a file hash generator and compare the result against the published value. Compare the whole string, not the first six characters, and paste rather than eyeball it. Human beings are remarkably bad at spotting one altered character in the middle of 64.

HMAC: the version that proves who sent it

If a plain hash cannot prove origin, HMAC is the fix. It combines the message with a secret key that both parties already hold, and produces a code that can only be generated by someone who knows that secret. Anyone can hash a message. Only a keyholder can produce a valid HMAC for it.

This is what sits behind webhook signatures and API request signing. The sender computes an HMAC over the payload and attaches it, the receiver recomputes it with the same shared secret, and if the two match the payload is both unaltered and from someone holding the key. If it does not match, discard the request without reading it. You can produce and check these values with an HMAC generator.

The limitation follows directly from the design: it is a shared secret, so both sides can generate valid codes. HMAC proves the message came from someone in the group. It cannot single out which member, and it cannot prove anything to a third party. That needs public-key signatures, which is a different tool for a different question.

What this is actually for, day to day

Finding duplicate files is the least glamorous and most useful application. Names, dates and sizes all lie. Hash the contents and identical files reveal themselves regardless of what they are called or where they were filed, which is how deduplication tools work and why they are trustworthy.

Change detection is the other everyday case. Hash a configuration file today, hash it next month, and any difference at all shows up immediately. Storing 64 characters is dramatically cheaper than storing a copy of every file, which is exactly how version control notices that you edited something.

For short strings, a quick hash generator settles the question of whether two values are really identical, including the invisible differences: a trailing space, a tab where you expected spaces, a line ending from the wrong operating system. The hash does not care that the two look the same on screen.

Underneath all of it, the model is a single sentence worth keeping. A hash proves sameness, not safety, and it proves sameness only against a value you had good reason to believe in the first place.