File

Drop a file hereor choose one from your computer

Checksums

Drop a file here

Success
Warning

The one question a checksum actually answers

A publisher ships a file next to a line reading SHA256: a94a8fe5cc.... That checksum is not there to prove the file is safe or trustworthy — it is there to prove the bytes you downloaded are the exact same bytes the publisher uploaded. A corrupted download, a truncated transfer, or a mirror serving a stale copy all produce a file that looks fine and opens fine, right up until it does not. Hashing your copy and comparing it to the published value catches all three before you run an installer or unzip an archive built on bad bytes.

This page computes MD5, SHA-1, and SHA-256, SHA-384 and SHA-512 from the SHA-2 family — because different publishers still choose different ones, sometimes for a single file — and matches whatever you paste against the right one automatically, rather than making you guess by the length of a hex string.

For this specific job, MD5 and SHA-1 being cryptographically broken does not matter the way it would for a password hash or a digital signature. Nobody is trying to forge a matching file on purpose here — the threat model is corruption, not an adversary, and any of the five algorithms catches an accidentally-changed byte with certainty.

The file never leaves your browser. It is read with the File.arrayBuffer() API and hashed locally — nothing is uploaded, which matters if the file you are checking is something you would rather not send anywhere, like an exported database or a private key bundle.

Verifying a download

  1. Drop the downloaded file in, or choose itThe whole panel accepts a drop, not just the dashed box in the middle.
  2. Find the checksum on the publisher's pageUsually next to the download link, labelled by algorithm — SHA256SUMS, a .sha256 sidecar file, or a line in the release notes.
  3. Paste it into the compare boxThe page detects which algorithm it is by length and checks it against that one automatically — you do not need to know which algorithm the publisher used before pasting.
  4. Trust a match, investigate a mismatchA match means the bytes are identical to what was published. A mismatch means re-download before you run anything from the file — do not assume it is close enough.

A checksum published over plain HTTP, next to a file also served over plain HTTP, does not protect against a deliberately tampered file — whoever can alter the download can alter the posted checksum beside it. It is still worth checking for corruption, but treat it as protection against accidents, not attacks, unless the checksum came from somewhere separate and verified, like a signed release page.

A short file, every checksum computed

The three bytes "abc" — small enough to see the whole input, and the exact string every hash algorithm's own published test vectors use.

One file, five checksumsRFC test vector
File3 bytes
abc
Checksumsmatches every published test vector
MD5
900150983cd24fb0d6963f7d28e17f72

SHA-256
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

When you need this

Verifying an OS image or installer before running it

Linux distributions, developer tools and firmware updates routinely publish a SHA256SUMS file beside their downloads specifically so this check is possible before you boot from or install something.

Confirming a large transfer completed cleanly

A multi-gigabyte export, backup, or dataset copied over a flaky connection can arrive the right size and still have a corrupted byte in the middle. A checksum comparison catches what a file-size check cannot.

Proving two copies of a file are identical

Comparing checksums is faster and more certain than comparing file sizes or modification dates when you need to know whether a file on two machines is genuinely the same, not just similarly named.

Hashing a string instead of a file

If what you actually have is pasted text rather than a file — an API key, a config value — use Hash Generator instead, which skips the file-picker step entirely.

What this page does

  • Computes MD5, SHA-1, SHA-256, SHA-384 and SHA-512 from the file, all at once, so you never have to know in advance which one a publisher used.
  • Paste a published checksum and it is matched against the right algorithm automatically, by length, with a clear match or mismatch result.
  • Reads the file with the browser's own File.arrayBuffer() and SHA family via crypto.subtle.digest — nothing is uploaded to a server.
  • Works from a drag-and-drop as well as a file picker, so the panel accepts a drop anywhere inside it.

Questions people actually ask

Which checksum should I compare against if the publisher lists several?

Any one that matches is sufficient proof the file is intact — they are all describing the same bytes. Paste whichever one is easiest to copy; this page will match it against the right algorithm regardless of which you choose.

The checksums do not match. What now?

Re-download the file before doing anything else with it. A mismatch means the bytes you have are not the bytes the publisher described — from a corrupted transfer, a stale mirror, or in rarer cases a tampered file — and none of those are safe to run or open as-is.

Can this handle a multi-gigabyte file?

Up to a point — this reads the whole file into the browser tab's memory to hash it, so a very large file can be slow or run into the tab's own memory limit. For genuinely large files, a command-line tool built for streaming — sha256sum on Linux, shasum on macOS, certutil -hashfile on Windows — handles them without that ceiling.

Why does this compute MD5 at all if it is broken?

Because plenty of still-current download pages publish MD5 checksums specifically for corruption checking, where a broken collision resistance does not matter — nobody is trying to forge a matching file, only checking that a transfer did not damage one. See the explanation above for the full distinction between that and anything security-sensitive.

Related tools

Specifications and references