ABC Tools

File Hashes and How to Verify a Download

After reading this you can take a file, compute its SHA-256 checksum, and decide with confidence whether it matches the checksum a download page published, without trusting anyone with your file.

What a file hash is

A hash function reads every byte of a file and produces a short fixed-length fingerprint. For SHA-256 that fingerprint is always 256 bits, written as 64 hexadecimal characters. It does not matter whether the file is 12 bytes or 12 gigabytes: the output is exactly 64 hex characters.

The point is that the fingerprint changes wildly if the input changes at all. Flip a single bit in a 700 MB installer, and roughly half of the 256 output bits flip too. There is no gentle drift. A one-byte change gives you a completely different 64-character string.

Here is the hook. The text abc (three bytes: 0x61 0x62 0x63) has SHA-256:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Change it to abd (one byte, 0x63 becomes 0x64) and the SHA-256 becomes:

a52d159f262b2c6ddb724a61840befc36eb30c88877a4030b65cbe86298449c9

The two share no visible structure. That is the property you rely on when verifying a download: a corrupted or tampered file cannot accidentally produce the same fingerprint as the good file.

When to use it, and when not to

Use a hash check whenever a download page publishes a checksum next to the file. Operating system images, database engines, and signing keys almost always do. You download the file, compute its SHA-256 locally, and compare against the published value. If they match, your copy is byte-for-byte identical to what the publisher released.

A hash check catches two different problems, and it is worth keeping them separate.

Accidental corruption
A truncated download, a bad disk sector, a flaky USB cable. Any hash, including MD5, catches this reliably.
Deliberate tampering
An attacker who replaces the file with a modified one. Here the hash function must be collision-resistant, so use SHA-256. MD5 and SHA-1 are broken for this purpose.

A hash check only proves your file matches the number you were given. If an attacker controls both the file and the checksum on the same page, they can publish a matching pair. That is why publishers sign their checksum files with a cryptographic key. The hash proves integrity; a signature proves who published it.

Do not use a hash to compare files that "look the same." Two exports of the same spreadsheet saved a second apart may differ in a timestamp byte and produce different hashes. The hash answers "are these bytes identical," not "do these mean the same thing."

The idea behind the numbers

SHA-256 processes the file in 512-bit blocks. It maintains eight 32-bit internal registers, starts them at fixed constants, and mixes each block into them using a fixed schedule of additions, rotations and bitwise operations. After the last block, the eight registers concatenated give the 256-bit output.

H = \text{SHA256}(m_1 \| m_2 \| \cdots \| m_n)

Here m_1 through m_n are the 512-bit blocks of the padded message, \| means concatenation, and H is the final 256-bit digest. Padding always appends a single 1 bit, then zero bits, then the original length as a 64-bit number, so that the total is a whole number of 512-bit blocks.

You do not need to trace the arithmetic. What matters is the consequence: the output space has 2^{256} possible values, which is about 1.16 \times 10^{77}. To have a 50 percent chance of two random files sharing a SHA-256 by accident, you would need roughly 4 \times 10^{38} files. That number is why an accidental collision never happens in practice.

Compare the output sizes. Fewer bits means a smaller haystack for an attacker searching for a collision.

Output size and collision resistance of common hashes
AlgorithmOutput bitsHex charsSafe against tampering?
MD512832No, collisions are cheap
SHA-116040No, collisions demonstrated
SHA-25625664Yes
SHA-38438496Yes
SHA-512512128Yes

A worked example you can reproduce

The tool hashes any file you drop in. To reproduce fixed numbers without a file, use the three-byte string abc, which is the standard test vector for SHA algorithms. Save those three characters to a file, or hash the bytes directly, and you should get the values below.

Hashing the bytes abc

  1. The input is three bytes: 0x61, 0x62, 0x63. Total length is 24 bits.
  2. SHA-256 pads this to one 512-bit block, then mixes it into the eight registers.
  3. The digest is ba7816bf...f20015ad, 64 hex characters.
  4. MD5 of the same bytes is 900150983cd24fb0d6963f7d28e17f72, 32 hex characters.
  5. SHA-1 of the same bytes is a9993e364706816aba3e25717850c26c9cd0d89d, 40 hex characters.

Every algorithm sees the same three bytes and returns a different fingerprint of a different length. All are correct; they just answer with different functions.

To feel how fragile the input is, change one byte and watch the whole digest turn over. The chart below counts, for the SHA-256 of abc versus abd, how many of the 256 output bits differ.

Identical input gives zero differing bits. A one-byte change flips about half of the 256 bits, here 131.

With no JavaScript: type any short text, then change one character, and compute the SHA-256 of each version. You will see the two 64-character digests share no visible pattern, and roughly 128 of the 256 bits differ regardless of how small your edit was.

Reading and interpreting the result

Comparing two 64-character strings by eye is error-prone. People check the first four and last four characters, decide they match, and move on. An attacker who can craft a near-match exploits exactly that habit. The safe method is to paste the published checksum and let a comparison run character by character. You want one verdict, not a squint.

Match the algorithm to the checksum you were given. A published value that is 64 hex characters is SHA-256. Forty characters is SHA-1. Thirty-two characters is MD5. If you compute SHA-256 and compare it against an MD5 string, they will never match even for a perfect file, because they are different lengths and different functions.

Hex is case-insensitive. BA7816BF and ba7816bf are the same value. Trim any leading or trailing spaces from a pasted checksum, and ignore a trailing filename that some checksum files append after the hash, as in ba78...15ad installer.iso.

Common mistakes

Most failed verifications are not tampering. They are process errors.

  • Hashing the wrong file. You downloaded app-2.1.dmg but pasted the checksum for app-2.0.dmg. Different versions, different bytes, different hash.
  • Comparing across algorithms. The page listed a SHA-256, you computed MD5.
  • Line-ending changes. If you download a text file and your tools convert LF to CRLF, you added one byte per line and the hash changes. Verify the raw downloaded file, not a re-saved copy.
  • Partial download. A hash mismatch after a slow connection often means the file is truncated. Check the byte size against the page before assuming the worst.

To confirm a suspected truncation or a line-ending change, open the file in the Hex Viewer and read the actual bytes. If the last bytes are missing or an expected 0x0A became 0x0D 0x0A, you have found your mismatch.

Related tools

When you verify a downloaded archive, you often want to look inside it next. The ZIP Creator & Extractor unpacks a ZIP entirely in your browser, so you can check its contents without installing anything. For byte-level inspection of any file, including checking padding, magic numbers or line endings, use the Hex Viewer linked above.

Frequently asked questions

Is MD5 safe to use at all?

For detecting accidental corruption, yes. MD5 will reliably catch a truncated or scrambled download. For protection against a deliberate attacker, no, because two different files with the same MD5 can be constructed in seconds. Prefer SHA-256 whenever a page offers it.

Why do I get a different hash than the website lists?

Check three things in order: you hashed the exact downloaded file, you used the same algorithm as the published checksum, and the file finished downloading completely. Those three account for almost every mismatch. A genuine tampering case is rare, but it is the reason the check exists.

Does hashing send my file anywhere?

No. The hash is computed in your browser from the bytes of the file you selected. The file and the result never leave your device. Files up to about a gigabyte are fine; very large files may exceed browser memory limits.

Can two different files ever have the same SHA-256?

In theory yes, because there are more possible files than possible 256-bit outputs. In practice no one has ever found such a pair, and finding one by chance would require on the order of 10^{38} files. Treat a SHA-256 match as proof the bytes are identical.

Which algorithm should I compute if I have a choice?

Compute the one the download page published, so you can compare like with like. If the page lists several, use SHA-256. It is the current default for both corruption detection and tamper resistance.

Try it yourself in the tool

Related tools

EPUB Converter & Metadata Editor

EPUB → TXT or Markdown, edit metadata, export chapters.

WhatsApp & Telegram Chat Analyzer

Upload a chat export: stats, heatmaps, reply times and a shareable dashboard card.

ZIP Creator & Extractor

Build ZIP archives and unpack them, all in the browser.

Hex Viewer

Inspect any file byte by byte, offsets + hex + ASCII.

Auto Analyst: Instant Statistical Report

Drop a CSV or Excel file and get a statistician’s report: data problems, distributions, every real relationship, key drivers and Simpson’s paradox warnings, in plain English.

CSV Viewer & Editor

View, edit, sort, filter and extract columns from CSV files.