SHA-256 vs SHA-512

Contents

• What that string of hex actually is
• So which one should you use?
• What a matching hash proves, and what it doesn't
• Your hashes don't match and the files look identical
• Verifying a download without fooling yourself
• Never use these for passwords
• SHA-256 vs SHA-512 at a glance

Your download finished. The project page shows a long string of hex characters underneath the link, labelled SHA-256, and you are meant to do something with it. Or a colleague sends you two files that look identical and asks why they hash differently.

Both questions have short answers, and both have a longer answer that matters more.

The short version. Use whichever algorithm the publisher used, because you can only compare like with like. SHA-256 and SHA-512 are both secure for file-integrity checks; SHA-512 offers no practical advantage over SHA-256 for normal file verification. A matching hash from a trusted source proves the bytes did not change in transit. It does not prove the file is safe. And if two identical-looking files produce different hashes, the cause is almost always an invisible byte, not a broken algorithm.

What that string of hex actually is

A cryptographic hash takes an input of any size and produces a fixed-length string called a digest. One word in, 64 hex characters out with SHA-256. A four-gigabyte disk image in, still 64 characters out. SHA-512 produces 128 hex characters instead.

The useful comparison is a tamper-evident seal on a parcel. The seal is far smaller than what it protects and tells you nothing about the contents. What it tells you is whether anything changed since the seal went on.

Try it on the Hash Generator: hash a sentence, change one letter, hash it again. The two results have nothing in common. A very small input change produces a completely different hash. That behaviour is called the avalanche effect, and it is the whole reason hashes are useful for spotting change.

So which one should you use?

Most of the time the decision has been made for you.

Use the algorithm the vendor, protocol, or specification publishes. If a project ships a SHA256SUMS file next to its downloads, you compute SHA-256. Computing SHA-512 instead gives you a perfectly correct digest that you have nothing to compare against.

When the choice really is yours, SHA-256 is the safer default, for a dull reason: support for it is close to universal. Every language, every platform, every command-line tool. SHA-512 is a fine choice for internal systems where you control both ends.

One detail that surprises people: SHA-512 is not slower despite producing twice the output. On 64-bit processors it is often the faster of the two, because it works on 64-bit words that suit the hardware. On 32-bit systems the order reverses. "Shorter must be faster" is not a safe assumption here.

Both remain sound. MD5 and SHA-1 do not — they have practical collision attacks and should not be used for cryptographic integrity checking. A collision occurs when two different inputs produce the same digest.

What a matching hash proves, and what it doesn't

This is where most of the misunderstanding sits, and it is worth being precise.

A matching hash proves the bytes you have are the bytes that produced the published digest. That is genuinely useful. It catches truncated downloads, corrupted transfers, failing disks, and accidental edits.

It does not prove the file is safe, and it does not prove it came from who you think. Consider what an attacker who can replace a file on a web server can also do: replace the digest printed on the same page. Now both match, and everything looks correct.

The check only means something if the digest reaches you through a channel the attacker does not control — a signed release, a separate trusted source, or a package manager that verifies signatures itself.

Put plainly: a hash catches accidents reliably, and catches attacks only when the digest itself is protected.

Your hashes don't match and the files look identical

Four causes account for nearly all of these, and none of them is visible on screen.

A trailing newline. Text files usually end with one. hello and hello followed by a newline are different inputs with entirely different digests. Copying text out of an editor adds or drops one constantly.

Line endings. Windows ends lines with carriage return plus line feed; Linux and macOS use line feed alone. A file that has crossed between systems, or passed through Git with line-ending conversion switched on, contains different bytes even though every character looks the same.

Character encoding. The same visible text saved as UTF-8 and as UTF-16 is a different byte sequence. A UTF-8 byte-order mark adds three bytes at the start of the file; a UTF-16 byte-order mark adds two.

Hashing the wrong thing. Hashing text copied out of a file is not the same as hashing the file itself. Formatted documents and archives may contain metadata or internal data that you cannot see on screen.

Work through those four before suspecting the algorithm. The algorithm is essentially never the problem.

Verifying a download without fooling yourself

1. Find the digest the publisher provides and note which algorithm it uses.
2. Compute the same algorithm over the file you downloaded.
3. Compare the values in full.
4. If they differ, download again before assuming an attack. Interrupted transfers are far more common than attacks.

Step three deserves emphasis. Each hex character carries four bits, so checking only eight of SHA-256's 64 characters tests just 32 bits. An attacker can expect to find a match after about 2^32 attempts, or 4.3 billion. That is within practical reach; matching all 64 characters is not.

Never use these for passwords

SHA-256 and SHA-512 are built to be fast. Password storage needs the opposite.

Storing passwords as plain SHA-256 digests means anyone who obtains your database can test billions of guesses per second on ordinary hardware. Speed, the virtue everywhere else, becomes the vulnerability.

Password storage needs a deliberately slow, salted, purpose-built function: Argon2id, scrypt, or bcrypt. The salt stops two users with the same password producing the same stored value; the slowness makes large-scale guessing far more costly.

If you are choosing passwords rather than storing them, Password vs Passphrase covers what actually makes one hard to guess.

SHA-256 vs SHA-512 at a glance

What to remember

• Match the publisher's algorithm. Comparing digests from different algorithms tells you nothing.
• Compare the full digest, never just the ends.
• Get the digest from a separate trusted source where you can.
• When two identical-looking inputs disagree, check for a trailing newline first.
• Never store passwords with either of these.

Both algorithms are available in the Hash Generator if you want to compare outputs for the same input side by side.