MD5 vs SHA-1 vs SHA-256: What Hashes Are For

MD5, SHA-1, and SHA-256 are the three names that show up in every “checksum” dropdown. They are not interchangeable, and none of them is how you should store passwords. DevOkk’s Hash Generator computes digests in the browser so you can match a published checksum or compare two strings without uploading the payload.

Hashing is not encryption, and not encoding

Encryption is reversible with a key. AES-GCM, age, a zip password - those hide bytes from someone who lacks the key.

Encoding is reversible with no key. Base64, hex, URL encoding. Anyone who sees the string can reverse it. See How to Encode and Decode Base64 if that is the job you actually have.

Hashing is one-way. The digest is a fingerprint. If you need to compare two blobs without sending the blobs, you send or store the digest. If you need to hide a blob, you encrypt.

The mix-up in tutorials is constant. “Hash this password with MD5 to secure it” is a 2005 sentence that should not survive a code review. Fast hashes are built to be fast. Password storage needs the opposite: a deliberately slow, salted KDF.

What each algorithm is still for

MD5 (128-bit). Broken for collision resistance. Researchers can produce two different files with the same MD5. It still appears on older download pages and in accidental legacy APIs. Use it only to match a digest someone already printed as MD5. Do not design anything new around it. Do not use it for signatures, certificates, or password storage.

SHA-1 (160-bit). Also broken for collisions (SHAttered and follow-ons). Git used it for many years; Git now treats SHA-1 as a compatibility problem, not a security feature. Same rule as MD5: verify an old published SHA-1 if you must, do not choose it for a new manifest.

SHA-256 (256-bit, SHA-2 family). The default that still means something for integrity. Software vendors publish SHA-256 sums. Certificate ecosystems moved here from SHA-1. For a “did I download the right ISO” check in 2026, this is the one you want.

SHA-384 and SHA-512 are the same family with longer outputs. Use them when a spec says so, not because a bigger number feels more serious for a 20-byte string.

There are other names in hash UIs (CRC32, Adler-32). Those are checksums for accidental corruption, not cryptographic hashes. They are fine for a zip integrity bit. They are not fine for “prove this build was not swapped.”

Collisions, in plain language

A collision is two different inputs, one digest. Birthday-bound math says collisions exist for every hash if you wait long enough. “Broken” means someone can find a collision with realistic compute, or can craft a second file that matches a digest they care about.

For MD5 and SHA-1, that is no longer theoretical. For a download checksum, a collision means an attacker could give you malware that still matches the MD5 on a careless website. SHA-256 makes that attack class impractical today.

A preimage attack is different: given only the digest, find any input that produces it. That is still hard for MD5 in many settings, which is why people get confused. “MD5 is broken” refers first to collisions, not to reversing a password in one shot. Attackers do not need to reverse MD5 to ruin password storage. They use rainbow tables and GPUs against a fast hash. That is enough.

How to checksum locally

1. Decide which algorithm the other side used. If the vendor printed SHA256 (thing.iso) = abcd…, do not hash with MD5 and wonder why it differs.
2. Open Hash Generator. No account.
3. Paste the text, or the same bytes you intend to compare. Watch encoding: hello and hello\n are different inputs. UTF-8 versus UTF-16 will disagree. File checksums on a vendor site are almost always over the raw file bytes, not over a textarea with a trailing newline you added.
4. Compare the hex case-insensitively. ABC and abc are the same digest.
5. If you are comparing two downloads, hash both with the same algorithm. Do not hash one and trust a webpage for the other if you have both files.

For a string you would not want in a third-party log - an unpublished document fragment, a token you are fingerprinting - local hashing is the point. Fingerprinting a token is not the same as storing a password. Do not build a login table out of SHA-256(password).

If you actually needed to encode the bytes for transport, switch to Base64 Encoder. Hashing will not give you the original back.

What hashes are not for

Password storage. Use Argon2id, bcrypt, or scrypt, with a unique salt, in the language’s well-reviewed library. SHA-256(password) is a fast hash. GPUs eat it.

Hiding API keys in source. The key is still in the repo if you shipped it. A hash of the key is a fingerprint, not access control.

Encryption. There is no “SHA-256 decrypt.” If a product UI says that, close it.

Proof that a website is honest. A SHA-256 on the same page that hosts the file is only as trustworthy as that page. Better vendors sign builds or publish sums on a second channel.

Browser Web Crypto implements SHA-1 and SHA-2 reliably. MD5 is not a standard SubtleCrypto algorithm in browsers; treat SHA-256 as the checksum you trust in a tab.

Picking an algorithm for the job in front of you

• Matching a README that says MD5: MD5, then consider asking the vendor for SHA-256 next time.
• New checksum you will publish: SHA-256.
• Git object ids in old repos: SHA-1, as a fact about Git, not as a recommendation.
• Password storage: none of these.

That is the whole decision table. The rest is folklore.

Fingerprint with SHA-256 unless you are matching an old digest

If you have a string or a small blob to fingerprint, open Hash Generator and pick SHA-256 unless you are matching an older digest.

If you thought a hash would hide the bytes, you want encoding or encryption instead - start with Base64 Encoder only if the job is transport, and do not call it encryption. For the rest of the local security toolkit, see Best Free Security and Encoding Tools.