A hash answers one question

A hash is a fixed-length fingerprint computed from a file's bytes. The same bytes always give the same digest; change one byte and the digest is entirely different. The length never varies with the file — a SHA-256 digest is 64 hex characters whether the input is a note or a ten-gigabyte installer — and the function only runs one way, so the file cannot be reconstructed from it.

All of which makes it good for exactly one question: are these bytes the same as those bytes?

What that question is worth

• Verifying a download. A publisher lists a digest; you compute it locally and compare. A match means you received what they released, with no corruption in transit.
• Catching corruption. Hash a large archive before and after copying or backing up. Matching digests mean the bytes survived; a mismatch flags a bad sector or a dropped connection before you rely on the copy.
• Finding true duplicates. Two files with different names and the same digest are the same file. Nothing else establishes that as cheaply or as certainly.

What it does not tell you

This is where nearly every misuse begins.

• Nothing about safety. A matching hash on a malicious file confirms you downloaded exactly the malicious file that was published. The check worked perfectly and told you nothing about whether to run it.
• It is not encryption. A digest is public by design and protects nothing. It is a check value.
• Not what changed. Different digests tell you something is different, not what or where.
• A digest on the same page as the download is weak. Whoever could alter the file could alter the number beside it. The check is strongest when the digest reaches you through a different channel than the file — a separate site, a signed release, a package manager.

Which algorithm

Four are offered: SHA-1, SHA-256, SHA-384 and SHA-512.

Use the one the publisher used. That is the whole decision — a digest is only useful compared against another digest of the same algorithm, so matching theirs matters more than picking the strongest.

In practice that is nearly always SHA-256, which is the standard for published checksums. SHA-384 and SHA-512 are longer variants and behave identically for confirming identity; they offer no practical advantage here. SHA-1 is included because you will still meet it on older checksums, and it is no longer appropriate where security rather than integrity is at stake — use it to check an old file against an old digest, not to make a new guarantee.

Local hashing, and one caveat

The file is read and hashed in your browser and never uploaded. That matters here specifically, because the things people verify are installers, archives and documents they have good reason not to hand to a third party.

The practical limit is memory rather than policy: the file has to be held in the browser to be hashed, so very large files can exhaust a tab where a desktop tool would stream from disk without trouble.

For hashing a string rather than a file, use the hash generator — and note the trap: a text file usually ends with a newline, so hashing the file and hashing the words you think are in it can give different digests.