File Checksum Verifier
Drop a file, paste the published checksum, get a MATCH or MISMATCH verdict — multi-GB downloads verified entirely on this device.
Drop files or folders here — they are read on this device, never uploaded.
No drag and drop needed — the button opens this device's file picker.
Digests are computed either way — paste an expected value for a MATCH / MISMATCH verdict.
Verdicts appear here — one card per file.
Press ? for shortcuts
Do it offline:$ sha256sum -c SHA256SUMS
How to use it
- Drop a file on the page — or several; each gets its own result card. On a phone, the picker button does the same job.
- Paste what the download page published into the expected pane: a bare digest, sha256sum or shasum output, a whole SHA256SUMS file, or BSD-style tag lines. The pane classifies the paste itself and switches on the matching algorithm.
- Tick extra algorithms in the checkbox row if you need more than the detected one — every selected digest is computed in the same single read of the file.
- Read the card: progress with an ETA while hashing, then per-algorithm digest rows with copy buttons and a MATCH or MISMATCH badge. A mismatch shows expected against computed with the differing digits marked.
- Fix a typo or paste a new value at any time — the verdict recomputes instantly from cached digests, without re-reading the file. ⌘/Ctrl + S saves every result as a SHA256SUMS manifest.
Drop the file you downloaded, paste the checksum its publisher lists, and read the verdict: MATCH or MISMATCH, with the first differing hex digit pointed out. Every byte is read and hashed on this device — watch the DevTools Network panel stay quiet while a multi-gigabyte image streams through with progress, an ETA and a working Cancel. SHA-256, MD5, SHA-1, SHA-512 and CRC32, alone or side by side.
How it works
Files never load into memory whole. The browser hands over a byte stream, a background worker pulls it in 4 MB slices, and each slice feeds incremental WebAssembly hashers — hash-wasm builds of MD5, SHA-1, SHA-256, SHA-512 and CRC32 — that carry running state from slice to slice, all selected algorithms in one pass. Memory stays flat whatever the file size, which is what makes a 6 GB ISO practical to verify here: the page keeps responding, progress and an estimated finish time tick along, and Cancel takes effect mid-read.
A pasted value classifies itself by shape. A single token is validated as hex, then its length names the algorithm — 32 characters is MD5, 40 is SHA-1, 64 is SHA-256, 128 is SHA-512 and 8 is CRC32 — with a chip stating the inference. Any other length is refused with the count in the message, and uppercase hex is folded to lowercase before comparison with a chip saying so. No inference is silent: everything the pane decides is printed where you can read it.
Multi-line pastes parse as checksum files in the two formats that cover practice: the GNU coreutils shape — digest, two spaces, filename, with an optional * marking binary mode and a leading backslash marking escaped names — and the BSD tag shape ALG (filename) = digest that shasum --tag and openssl dgst emit. Blank lines and # comments skip. Entries pair with dropped files by exact name first, then by basename, so a manifest's ./ubuntu.iso still finds the ubuntu.iso you dropped; every line that pairs with nothing is listed by name, never silently dropped.
The verdict is a byte comparison, not an impression. Computed and expected digests compare case-insensitively; on a mismatch the differing hex digits are marked and the position of the first one is printed. Digests are cached per file, so editing the expected pane re-verifies without re-reading anything, and ticking one more algorithm computes only the digest that is missing. Check it yourself: keep the DevTools Network panel open while a file hashes — its bytes never enter a request.
Examples
hello2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 — MATCHThe built-in sample run: sample.txt holds these five bytes, and the expected pane is prefilled with the digest above. Detection chips it as 64 hex characters — treated as SHA-256, the computed and expected values agree in every digit, and the badge lands on MATCH.
AAF4C61DDCC5E8A2DABEDE0F3B482CD9AEA9434D40 hex characters — treated as SHA-1An uppercase paste, as checksums are often published. The length picks the algorithm — the output line is the chip, verbatim — and a second chip reports: Expected checksum was normalized to lowercase before comparison. Against the sample file this value verifies as its SHA-1, so case alone can never cost you a MATCH.
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 sample.txt
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 release-notes.txtsample.txt — MATCH
1 checksum line matched no file: "release-notes.txt".A two-line SHA256SUMS paste with only sample.txt dropped: the first line pairs by filename and verifies, and the line that pairs with nothing is listed in a warning — the second output line is that warning, verbatim. Drop release-notes.txt later and the entry is waiting.
SHA256 (sample.txt) = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824BSD-style checksum lines detected ("ALG (filename) = digest" format).The tag format, exactly as shasum -a 256 --tag prints it. It parses to the same entry as example 3's first manifest line — algorithm, digest and filename — and verifies the sample file identically; the output line is the format chip.
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855The edge case: a 0-byte file. Hashing nothing is well-defined, so the row shows this digest with the chip 0-byte file — this is the well-known digest of empty input. Seeing it MATCH a published checksum would mean the publisher hashed an empty file too.
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
A 0-byte file verifies like any other
Empty input has perfectly defined digests — d41d8cd98f00b204e9800998ecf8427e for MD5, example 5's value for SHA-256 — so a zero-byte file gets real digest rows plus a chip naming the situation. When a fresh download verifies against one of these values, the transfer ended before its first byte arrived.
Formatting never manufactures a MISMATCH
Comparison trims whitespace and ignores case, and each applied normalization is declared as a chip. Anything beyond formatting — a character that is not hex, a length no supported algorithm produces — stops with a typed message pointing at the exact position, so the verdict only ever states a fact about bytes.
GNU and BSD checksum lines both parse
sha256sum writes digest-first lines with a two-space separator; shasum --tag and openssl dgst write the tag form instead. Both parse here, mixed freely in one paste; the GNU * binary-mode flag is noted and stripped from the filename, and coreutils-escaped names are unescaped with a chip counting them.
A backgrounded tab keeps hashing
The worker's read loop is driven by stream reads, not by animation frames or timers the browser throttles, so switching tabs does not pause a long run. Start a multi-gigabyte verification, go read the release notes, and the verdict is waiting when you come back.
Folder drop is Chromium-first; the picker reaches everywhere
Dropping a folder enumerates it recursively where the browser exposes directory entries — Chromium-family desktops today — up to the 256-file cap, and says so plainly where it cannot. The picker button and phone file sheets handle one or many files everywhere.
MD5 and SHA-1 catch corruption, not tampering
Any accidental byte flip changes an MD5 or SHA-1 digest, so both still expose truncated or damaged downloads. What they no longer resist is an adversary: manufacturing two inputs with one MD5 digest is practical — RFC 6151 documents the break — and SHA-1 has published collisions too. When the publisher offers SHA-256 or SHA-512, verify against that value instead.
CRC32 is an error-detecting code, not a fingerprint
Eight hex characters — the check value for the digits 123456789 is cbf43926 — make CRC32 quick at spotting transmission noise in firmware images and ROM sets, and trivial to forge deliberately. This page accepts 8-character values because they exist in the wild, and leaves proof of integrity to the SHA family.
Common errors
Expected checksum is not valid hex: `g` at position 5- One character in the paste is not a hex digit, and the message counts to it — here a g where only 0–9 and a–f can appear. The usual cause is a copy that caught surrounding text or a transcribed character. Jump to error focuses the pane at that exact spot; the paste stays put while you repair it.
This doesn't look like an MD5/SHA digest (unexpected length 47)- No supported algorithm produces 47 hex characters, so a comparison would be meaningless — values verify here at 8, 32, 40, 64 or 128 characters. A stray length nearly always means the copy lost characters at one end: re-select the published value from first digit to last.
1 checksum line matched no file: "release-notes.txt".- The pasted manifest names a file that was not dropped, so that line has nothing to check against. Drop the missing file to complete the run, or ignore the warning when you only meant to verify some of the listed files — matching tries the exact name, then the basename.
Expected input is larger than the 1 MB limit for this tool. For big checksum files use the CLI: sha256sum -c SHA256SUMS- The expected pane takes checksums, and a paste near a megabyte is almost always the downloaded file's own contents in the wrong box — the file belongs in the drop zone, where multi-gigabyte sizes stream fine. For a checksum list that genuinely is this large, the CLI line does the whole job locally.
FAQ
How do I verify a checksum on Windows?
In Command Prompt, certutil -hashfile ubuntu.iso SHA256 prints the digest; in PowerShell, Get-FileHash ubuntu.iso does the same and defaults to SHA-256. Both leave you comparing sixty-four characters by eye — or drop the file here, paste the published value, and the comparison runs digit by digit with the verdict spelled out.
How do I verify a checksum on macOS?
shasum -a 256 ubuntu.iso prints the SHA-256; with a published SHA256SUMS file saved alongside the download, shasum -a 256 -c SHA256SUMS checks every listed file and prints OK per line. The same manifest pastes straight into this page's expected pane if a terminal is not where you want to be — drop the files beside it.
How do I verify a SHA-256 checksum on Linux?
From the download directory, sha256sum -c SHA256SUMS reads the manifest and reports OK or FAILED per file; bare sha256sum ubuntu.iso prints a digest-first line in exactly the format this page's manifest download uses. Wherever you check, take the published value from the project's own page rather than the mirror that served the file.
Is my file uploaded when I drop it here?
No. The browser reads the file from disk and hashes it on this device; its bytes, name and digests never enter a network request. That is a checkable claim rather than a promise: open the DevTools Network panel, drop a large file, and watch nothing leave while the progress bar runs.
What does MISMATCH mean?
The file's bytes are not the bytes the published checksum was computed from. In rough order of likelihood: an incomplete or corrupted download, the wrong variant of the right project — another version, architecture or build — or, the case checksums exist for, a file someone altered. Re-download and re-verify first; if the mismatch survives, fetch file and checksum from the primary site before trusting either.
Which checksum should I verify when a page lists several?
The strongest one on offer — SHA-256 or SHA-512 — and one is enough, since every listed digest was computed over the same bytes. MD5 or CRC32 alone still rules out accidental corruption, just not deliberate tampering, so weigh a page that offers nothing stronger accordingly.
What is a SHA256SUMS file?
A plain-text manifest, one line per file: SHA-256 digest, two spaces, filename — the checksum-line format the GNU coreutils manual defines and sha256sum -c consumes. Lines starting with # are comments, and a * before the filename marks binary mode. Paste one into the expected pane and each line is matched to your dropped files by name; ⌘/Ctrl + S produces the same format back.
Keyboard shortcuts
- ⌘/Ctrl + Enter
- Re-run the verification now against the cached digests.
- ⌘/Ctrl + S
- Download every result as a SHA256SUMS manifest — missing SHA-256 digests are computed first. On this page it saves the manifest, not the page.
- ⌘/Ctrl + C
- Copy that same manifest while focus is in the tool and nothing is selected; an actual selection copies only itself.
- ⌘/Ctrl + Shift + C
- Copy the manifest even while a selection exists.
- t
- Cycle the color theme (ignored while typing in the expected pane).
- ? or ⌘/Ctrl + /
- Open the keyboard shortcut overlay.
- Esc
- Close the topmost dialog — dropped files and the expected paste are never cleared by it.