Hash Generator

Two digests are identical or unrelated

Change one character of the input and roughly half the output bits flip, with no visible relationship to what changed. There is no such thing as a digest that is nearly right: editing a single digit in a paragraph produces a value that shares no more with the original than two unrelated files would. Every function here behaves that way, and it is the property that makes a digest worth comparing at all.

It also settles how much of one you need to look at. Because there is no gradient to exploit, the question is only how many bits you are checking and what it would cost someone to produce a different input with the same prefix:

SHA-256 as 64 hex characters, compared in full
        256 bits   a colliding pair needs ~2^128 work   not reachable

      first 32 hex characters only
        128 bits   a colliding pair needs ~2^64 work    out of reach

      first 16 hex characters only
         64 bits   a colliding pair needs ~2^32 work    one machine, minutes

      first 8 hex characters only
         32 bits   a colliding pair needs ~2^16 work    instant, on a laptop

      The cost is the square root of the space rather than the space itself,
      because a colliding pair is found by generating both halves at once.

That last line is the birthday bound, and it is the reason a truncated digest is weaker than the characters suggest. Dropping half of a SHA-256 does not halve its strength — it squares it. For spotting an accidental difference between two files, a short prefix is plenty and is what most checksum displays show. For standing up to someone who wants to deceive you, the full value is the minimum, and the comparison has to be against a value you got from somewhere other than the file itself.

What a match proves

A digest answers one question: are these two byte streams identical. Everything else people read into it is either a second question or an assumption. Match the published digest and you know the file arrived intact and is the file they hashed — not that the bytes are harmless, and not that the page you read the digest from belonged to them. Those are separate claims, and they need separate evidence: a signature, a second domain, a release page you reached through something you already trust.

This is where the difference between the functions stops being academic. MD5 and SHA-1 still detect accidental damage perfectly well — a truncated download, a corrupted disk, a file that did not finish copying all differ from the original. What they cannot do is resist someone constructing two different files with the same digest on purpose, which is a thing that has been done for both. If the only adversary you have is a flaky network, either is fine. If a published checksum is standing between you and a tampered installer, it has to be SHA-256 or better, from a source you trust independently of the file.

Why the same text does not always hash the same

Most disagreements about digests are not about the function. They are about bytes you cannot see. A text file has its own line endings, often a byte-order mark at the front, and possibly an encoding that is not UTF-8, so copying its contents into a text box and hashing the file both produce valid digests of different inputs. Opening a file and re-saving it can change the trailing newline, which is a byte, and one byte is enough.

Unicode adds a subtler version. A character with an accent can be stored as a single code point or as a base letter followed by a combining mark, and the two are different bytes that render the same on screen. Nothing about either form is wrong — they are both valid Unicode — but they are not the same input, and hashing does not normalise. When two values that look identical refuse to match, the answer is usually at the byte level rather than in the algorithm: a trailing space, a carriage return, a non-breaking space where a normal one was expected.

Which one to reach for

SHA-256 is the default because it is the one everybody else checks. Release pages, package indexes and container registries publish it, so a value computed here has something to compare against — a stronger function with nothing to match is not more useful. SHA-512 is not stronger in any way that matters for a file digest; on 64-bit hardware it is often faster, because its internal operations line up with the register width, and that is the whole of the advantage.

MD5 survives for the same reason SHA-1 does: published digests for both still exist, and old download pages have not been rewritten. Reading them is fine. Producing a new one to publish is not, and neither is building anything that depends on a collision being hard. Where several files need hashing at once, BLAKE3 is the one designed for it and will outrun everything else in the table on the same machine.

Two adjacent tools cover the cases this one does not. When two files differ and you want to know where rather than whether, the Diff Checker marks the lines that disagree. When the job is naming something so that two things cannot collide, the UUID Generator is the tool built for that, and it needs no secret to do it.