What a hash is, checksums and SHA-256 in practice

What a hash function is

A hash function turns an input of any size (a piece of text, a whole file, a binary blob) into a fixed-size output, typically written as a short hexadecimal string. The four properties that matter are: the same input always yields the same output; a tiny change in the input drastically changes the output; you cannot recover the input from the output; and finding two distinct inputs that produce the same output should be computationally infeasible (collision resistance).

Those properties make a hash usable as a short digital fingerprint of any piece of data. If a vendor publishes SHA-256: abc123... next to a download, anyone who fetches the file can recompute the hash locally and confirm it matches. If it matches, the file is bit-for-bit the one the vendor published. If not, it has been modified, corrupted, or replaced.

The hash families in widest use today are SHA-2 (SHA-256, SHA-384, SHA-512), published by NIST in 2001 and still considered safe for integrity and digital signatures. MD5 (1992) and SHA-1 (1995) are still around for historical compatibility but are no longer safe in cases where an attacker can manipulate the input.

Hash vs checksum

The two terms are often used interchangeably, but they are not exactly the same. A “checksum” is any function that produces a fingerprint of a block of data to detect transmission or storage errors. Early CRCs (CRC-16, CRC-32) are checksums designed to catch accidental bit-flips on networks or disks; they are fast, cheap, and never claimed to resist an attacker. Two files colliding under CRC-32 is not a surprise.

A cryptographic hash function is a particular kind of checksum that additionally resists intentional collisions. SHA-256 not only catches accidental corruption, it also resists the case where someone actively searches for another piece of content with the same hash. That property is what separates “verify the file is not damaged” from “verify nobody swapped the file for a tampered one”.

In practice, when a project publishes a SHA256SUMSfile or a “Checksum (SHA-256)” field on its download page, it is using a cryptographic hash as a checksum. That is the common shorthand: on a web page, “checksum” usually refers to SHA-256 or SHA-512 even when the term in the abstract covers weaker things like CRC.

SHA-256, SHA-1, SHA-512 and MD5: when to pick which

The calculator ships five algorithms. The right pick depends on how sensitive the use case is.

Rule of thumb: SHA-256 for integrity and signatures; SHA-512 when the receiving system asks for it; SHA-1 only on specific legacy systems (Git); MD5 only for low-risk checksums where nobody is going to tamper with the file. For passwords, none of these; use a real password hashing library.

How to verify a download with SHA-256

The classic use case is checking that the Linux distribution ISO you just downloaded matches the one the project published. Three steps:

1. On the official download page, find the published SHA-256. It is usually shown next to the ISO link or inside a separate file called SHA256SUMS or similar. Copy it as-is.
2. Compute the SHA-256 of your local file. On this page: drop the file into the file-hashing area, pick SHA-256, and wait. In a Linux/macOS terminal: sha256sum my-file.iso. In PowerShell: Get-FileHash -Algorithm SHA256 my-file.iso.
3. Paste the published hash into the “Expected hash” field of the calculator (or compare visually). The calculator ignores whitespace and case, so it does not matter if the vendor publishes the hash in uppercase and the tool emits it lowercase.

If both hashes match, the file is bit-for-bit identical to what the vendor published. If they do not match, the file is corrupted, modified, or you picked a different algorithm than the one the vendor used (for example, you computed SHA-512 but the site publishes SHA-256).

One important caveat: the SHA-256 published by the vendor is only as trustworthy as the page it is read from. If an attacker controls the download page, they also control the published hash. For cases where this matters, projects additionally publish GPG signatures of the SHA256SUMS file. Useful heuristic: if the hashes live on the same page and under the same control as the download, they are good enough to catch accidental corruption; for protection against an attacker, you need a cryptographic signature over the hash, not just the hash on its own.

Why MD5 is broken but still shows up in old downloads

MD5 was published in 1992 and used heavily for more than a decade. Trouble arrived when researchers showed, first in theory and then in practice, that it was possible to deliberately produce two different files with the same MD5. By 2008 collisions could be generated in minutes on commodity hardware; today it takes seconds.

That means MD5 fails the core property of a cryptographic hash: resistance to intentional collisions. It is still acceptable for catching the case where a file gets corrupted by a random bit-flip when copying it from an old disk or over a flaky network, because in that scenario nobody is hunting for a collision: the flip is random. It does not work for catching malicious tampering: someone can replace the original file with another that has the same MD5 and the verification still passes.

MD5 still appears in older downloads, in legacy package mirror manifests, and in hashes embedded in old code. The calculator supports it because there are legitimate uses for verifying low-risk checksums, but the UI flags the algorithm as LEGACY and every recommendation steers you toward SHA-256.

Why you should not use SHA-256 or MD5 for passwords

Plain hashes (MD5, SHA-1, SHA-256, SHA-384, SHA-512) are designed to be very fast. That speed is exactly what you want for verifying file checksums: computing SHA-256 over a 4 GB ISO should take seconds, not hours. But that same speed is what makes them unsuitable for storing passwords.

When an attacker steals a database of SHA-256-hashed passwords, they can try billions of guesses per second on modern hardware (GPUs, specialised ASICs). Within hours or days they have every weak password in the database. Adding a salt mitigates precomputed table attacks (rainbow tables) but does not stop straight brute-force.

Functions designed for password hashing apply two extra mechanisms: a mandatory salt (different per user, kills rainbow tables) and a deliberate cost factor that makes each individual attempt take milliseconds instead of nanoseconds. That cuts the attacker rate from billions per second to hundreds per second, which changes the feasibility calculation.

The three standard families:

• bcrypt: long-standing standard, configurable cost factor, automatic salt.
• scrypt: adds memory cost to resist GPU attacks.
• argon2: winner of the 2015 Password Hashing Competition, considered today's default.

These functions are not in this calculator because their correct use involves operational decisions (parameters, salt storage, version handling) that belong in the backend that stores the passwords, not in a general-purpose interactive tool. Rule of thumb for the calculator: if what you are hashing is a password, you are in the wrong place.

Common mistakes

• Confusing encoding with algorithm. The same hash can be written in hex (default, 64 characters for SHA-256), base64 (44 characters with padding), or any other binary encoding. Changing the encoding does not change the underlying hash: it is the same number, written differently. If your verification fails because “the strings differ”, check that both sides are using the same encoding before assuming tampering.
• Comparing hashes with different case. Hex is case-insensitive by convention. ABC123 and abc123 are the same hash. The calculator compares case-insensitively, but a naive shell diff does distinguish. Normalise before comparing.
• Forgetting whitespace and newlines. A shell command like echo “hello” | sha256sum appends a trailing newline, so the hash is of “hello\n”, not “hello”. To hash the literal string, use printf “hello” | sha256sum, or paste the string into the calculator without trailing newlines.
• Expecting a hash to be reversible. A hash function is NOT encryption: there is no mathematical way to recover the input from the output. Pages that claim to “decode” a hash are really just looking up the hash in a database of precomputed common inputs. For non-trivial data they do not work.
• Treating MD5 collisions as a theoretical concern. MD5 collisions are generated on commodity hardware in seconds. Any security process that relies on MD5 against an attacker is broken in practice, not just “in theory”.

How to use the calculator

The hash and checksum calculator accepts pasted text or dropped files, supports SHA-256, SHA-1, SHA-384, SHA-512 and MD5, and returns the result in hex (default) or base64. It also includes an “Expected hash” field to compare against a hash published by a vendor. Everything is computed in your browser: SHA-* via Web Crypto API and MD5 via local JavaScript. No text, file, or expected checksum is sent to any server.

Typical use cases: verifying an ISO before installing it, generating a stable identifier from a string to use as a key in code, checking that a file has not changed between two copies, computing the hash that an external system asks you to enter manually.

For passwords the same rule applies as before: use a real password hashing library (bcrypt, scrypt, argon2), not this calculator. The calculator is for content integrity and verification, not for authentication.