Skip to content

File hash checker — verify a download’s checksum

Hash any file with SHA-256, SHA-512, SHA-1 or MD5 and compare it against a published checksum. Streams multi-gigabyte files without uploading a byte.

  • Runs in your browser
  • Files are never uploaded
  • Free, no account

The file never leaves your device. It is read straight off your disk in 4 MB slices and hashed in this tab, so a 40 GB disk image works the same as a 40 KB text file — and none of it is uploaded. That is also why this is the only honest way to verify a download: an upload-based checker would have to receive the very file whose integrity you are trying to prove.

Drop a file to hashAny size, any type, nothing is uploaded.Any file

How to verify a download's checksum

  1. Drop the downloaded file onto the panel above. Any size and any type. The file is read from your disk in slices, never uploaded.
  2. Paste the checksum the publisher gave you. A bare hex string, a whole sha256sum line, a BSD-style SHA256 (file) = … line, or a colon-separated fingerprint all work. The algorithm is detected from the digest length and enabled automatically.
  3. Wait for the pass to finish. Throughput and progress are shown as it goes, and you can cancel at any point.
  4. Read the verdict. A match means the file on your disk is byte-for-byte the file the publisher hashed. A mismatch means it is not — do not open it.

Why an upload-based checksum tool is the wrong idea

The point of verifying a checksum is to establish that a file you do not fully trust is genuine. Uploading that file to a website inverts the whole exercise: you hand the suspicious bytes to a third party and then trust their word about them. You also pay to upload potentially gigabytes, and you have no way of knowing what happens to the file afterwards.

Verification only means anything where the file already is. This page reads the file directly from your disk with the File API, hashes it locally, and makes no network requests at all after it loads — you can confirm that in your browser's network panel while a 10 GB image is being processed.

Which algorithm should you use?

Algorithm Digest size Hex characters Status
MD5 128 bits 32 Broken for security. Collisions are trivial to construct. Fine for spotting corruption.
SHA-1 160 bits 40 Broken since the 2017 SHAttered collision. Legacy checksums only.
SHA-256 256 bits 64 The current default for release checksums, signatures and integrity checks.
SHA-512 512 bits 128 SHA-2 with 64-bit words. No stronger in practice, often faster on 64-bit CPUs.

The distinction that matters is between accidental and deliberate change. For catching a download that got truncated by a flaky connection, MD5 is perfectly adequate — a corrupted file will not produce a matching digest by chance. For proving that nobody swapped the file for a malicious one, MD5 and SHA-1 are useless: an attacker who controls the file can construct a different file with the same digest. Use SHA-256 whenever the publisher offers it, and treat a project that only publishes MD5 as a mild warning sign.

A checksum does not prove authenticity on its own

If the checksum sits on the same web page as the download link, an attacker who can replace the file can also replace the checksum. Checksums protect against corruption and against a compromised mirror; they only protect against tampering when you get the digest from an independent source — a signed release file, the project's signing key, a different domain, or a copy you saved earlier.

Hashing very large files in a browser

The browser's native crypto.subtle.digest is fast but has no streaming interface: it wants the whole input in memory at once, which rules out anything bigger than a couple of gigabytes. This tool therefore uses native digests for small files and switches to its own incremental implementations of MD5, SHA-1, SHA-256 and SHA-512 for large ones, feeding them 4 MB at a time and yielding to the browser between slices so the page stays responsive.

Peak memory stays in the low megabytes regardless of file size, so the practical limit is how fast your disk can be read rather than how much RAM you have. The implementations are checked against the standard FIPS 180-4 and RFC 1321 test vectors, including the awkward cases around block and padding boundaries.

The checksums do not match — now what?

  1. Check you are comparing the right algorithm. A SHA-256 digest will never match an MD5 one. The tool detects this from the length, but a publisher listing several files can make it easy to grab the wrong line.
  2. Check you have the right file. Different architectures, editions and point releases have different checksums, and browsers sometimes append (1) to a re-downloaded file rather than replacing it.
  3. Download it again, ideally from a different mirror. Most mismatches are interrupted or truncated downloads, and a second attempt fixes them.
  4. If it still does not match, stop. Do not run the installer to "see what happens". Report it to the project, and get the file from the canonical source.

Command-line equivalents

Everything here matches what your operating system's own tools produce, so you can cross-check:

sha256sum ubuntu-24.04.iso            # Linux
shasum -a 256 ubuntu-24.04.iso        # macOS
certutil -hashfile ubuntu.iso SHA256  # Windows
Get-FileHash ubuntu.iso -Algorithm SHA256  # PowerShell

The digests are identical — a hash function has exactly one correct answer for a given set of bytes. This page simply saves you from remembering which of those four commands your current machine wants.

Questions

Is there a file size limit?

No. The file is read from disk in 4 MB slices and folded into the running hash, so memory use stays flat whether the file is 40 KB or 40 GB. The only limit is how fast your disk can be read; the panel shows throughput as it goes and you can cancel at any point.

Why does an online checksum tool that uploads the file make no sense?

Because you would be handing the very file whose integrity you doubt to a third party, and then trusting their answer about it. Verification only means something if it happens where the file already is. Here the bytes never leave your machine — this page makes no network requests after it loads.

How do I paste the expected checksum?

Any common form works. A bare hex string, a full sha256sum line such as "9fdc… ubuntu.iso", a BSD-style "SHA256 (file) = 9fdc…" line, or a colon-separated fingerprint. The algorithm is detected from the digest length — 32 hex characters is MD5, 40 is SHA-1, 64 is SHA-256 and 128 is SHA-512 — and that algorithm is enabled automatically.

The checksums do not match. What should I do?

Do not open the file. A mismatch means the bytes on your disk are not the bytes the publisher hashed: an interrupted or corrupted download, a mirror serving an older build, or in the worst case a tampered file. Download it again from the original source and check it again before you run it.

Should I trust an MD5 or SHA-1 checksum?

For catching an accidentally corrupted download, either is fine. For proving that nobody tampered with a file, neither is: practical collision attacks exist against MD5 and SHA-1, so an attacker who controls the file can produce a different one with the same digest. Prefer SHA-256 whenever the publisher offers it.