Checksum Verifier

How to Verify a File

Features

What a Checksum Actually Verifies

A checksum is a short, fixed-length fingerprint of a file's exact contents, produced by a hash function. Change a single byte anywhere in the file — one corrupted sector during a download, one byte flipped by a bad network connection, one character altered by an attacker — and the checksum comes out completely different. That property is what makes a checksum useful for exactly one question: is this file, byte for byte, the same file the checksum was originally computed from? It cannot tell you whether that original file was trustworthy, well-written, or free of vulnerabilities — only whether what you have now matches what was published.

Most people only ever need to answer that question once, with one file and one checksum someone handed them. But real-world verification often looks different: a Linux distribution publishes forty checksums in one file for forty different downloads, a QA engineer needs to know if two build artifacts are identical without a published checksum for either, or a systems administrator inherits a folder of vendor files and a manifest and needs to check all of them before deployment. This tool is built around all three of those situations, not just the simplest one.

Checksums Arrive in More Formats Than You'd Expect

Paste a bare hash and it works immediately, but that is rarely how checksums actually show up in the wild. GNU coreutils tools — sha256sum, md5sum — produce lines like 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 file.iso, with two spaces and the filename attached. macOS and BSD's shasum and md5 commands instead produce SHA256 (file.iso) = 9f86d0…. Copying only the hash out of either format by hand is fiddly and error-prone at 64+ characters. Paste the entire line here instead — File vs Hash mode recognizes both formats, extracts the hash, and shows you the filename it was originally computed for, so you can confirm at a glance that you're comparing the right published value against the right file.

Batch Manifest Mode: Verifying an Entire Release at Once

A SHA256SUMS file — or its MD5SUMS, SHA1SUMS, and SHA512SUMS relatives — is the standard way open source projects and Linux distributions publish integrity data for an entire release: one line per file, every download covered by a single text file. Checking that kind of manifest one hash at a time, copying each line into a single-file tool, defeats the purpose of publishing them together in the first place.

Batch Manifest mode reads the whole file at once — paste its contents, or drop the .txt file directly onto the manifest field — then accepts every file you want checked, dropped in together. Each manifest line is matched to an uploaded file by filename, verified independently, and reported with one of four outcomes: a clean match, a mismatch (with both the expected and computed hash shown so you can see exactly how they differ), a file the manifest lists that you haven't provided yet, or a file you've added that the manifest never mentions at all. The scoreboard at the top of the results gives you the whole picture — say, 38 matched, 1 mismatched, 2 missing — before you scroll through a single row.

File vs File: Comparing Two Copies Without a Published Checksum

Not every verification starts with a checksum someone handed you. Sometimes you just have two files and want to know if they're actually the same — a file before and after copying it to a USB drive, a backup versus the live original, or two downloads of the same installer pulled from different mirrors. File vs File mode drops the need for a checksum entirely: give it both files, and it computes and compares every algorithm for you, ending in a single, unambiguous "identical" or "different" verdict, with the individual algorithm rows available underneath if you want to see exactly which ones were compared.

Who This Actually Helps

• Anyone downloading a Linux ISO or firmware image — verifying against the distribution's published SHA256SUMS before burning it to install media
• Release and QA engineers — confirming a batch of build artifacts matches a manifest before a deployment, or that two builds produced on different machines are identical
• System administrators — auditing a folder of vendor-supplied files against an accompanying checksums list before rolling them out
• Anyone transferring large files over an unreliable connection — confirming nothing got corrupted along the way with a direct File vs File comparison
• Security-conscious downloaders — spot-checking that a file wasn't silently swapped by a compromised mirror before running it

A Checksum Match Is Not the Same as "Safe"

This is worth being direct about, because it's the single most common misunderstanding about what checksum verification actually buys you. A matching checksum proves the file you have is identical to whatever the checksum was computed from — nothing more. If an attacker compromises both a download and the checksum published next to it, both will match perfectly, and the match will tell you nothing is wrong even though everything is. Checksum verification protects you from corruption, partial downloads, and a mismatched or compromised mirror serving a different file than the one the official checksum describes — it is not, on its own, a guarantee that the original file is trustworthy. Get your checksums from the same trusted source as the download itself, ideally over a connection you also trust.

Why Browser-Based Verification Is Fine for Sensitive Files

Every read and every hash computation happens locally, using the Web Crypto API for SHA-1 through SHA-512 and a local JavaScript implementation for MD5. No file content, filename, or checksum you paste is transmitted to ToollyX or anyone else — you can disconnect from the network after the page loads and the tool keeps working exactly the same. That matters for confidential vendor deliverables or internal build artifacts you'd rather not run through a server you don't control, even a trusted one.

Tips for Getting a Clean Result

• Copy the whole checksum line, not just what looks like the hash. Pasting the entire GNU or BSD-format line lets the tool confirm the filename it was computed for, catching a "right hash, wrong file" mix-up you'd otherwise miss.
• Use Batch Manifest mode the moment you have more than two or three files. Copying individual hashes out of a SHA256SUMS file one at a time is exactly the tedious, error-prone process this mode exists to remove.
• Don't panic at a single "missing" or "extra" result in Batch mode. Those aren't failures — they just mean a file hasn't been added yet, or wasn't listed in the manifest at all. Only "mismatch" indicates an actual problem.
• Prefer SHA-256 or higher whenever a source offers a choice of algorithms. If a project publishes both an MD5SUMS and a SHA256SUMS file, verify against the SHA-256 one.
• Get the checksum from the same trusted place as the file. A checksum copied from an unrelated forum post or a random search result verifies nothing meaningful — see the note above on what a match actually proves.

When This Tool Isn't What You Need

If you need to generate a fresh checksum with no comparison in mind, the plain Hash Generator is the simpler, more direct tool for that. If what you actually need is proof of authenticity from a specific sender — not just that a file matches a checksum anyone could have computed — you want the HMAC Generator, which adds a shared secret key into the computation. And if you're checking password hashes rather than file integrity, none of these apply — use the Bcrypt Hash Generator instead, since passwords need salting and deliberate slowness that file checksums don't.