Local File Hash Verifier

Why verify file checksums

A checksum is a short fingerprint derived from a file's contents. If even a single byte changes, whether through corruption in transit, a failed download, or deliberate tampering, the resulting checksum changes completely.¹ Publishers of firmware, OS images, and software installers post expected checksums alongside their downloads so you can confirm that what you received is exactly what was released.

Verification matters most for security-sensitive files, where the consequences of a bad download are severe. A tampered installer can silently backdoor an entire system the moment you run it, and a corrupted firmware image can brick a device that has no easy recovery path. A failed checksum match catches both failure modes before you execute or flash anything, turning a potentially irreversible mistake into a quick re-download.

SHA-256: the current standard

SHA-256 is a NIST-approved SHA-2 algorithm, and many modern software publishers, package managers, and operating systems use it to publish checksums.¹ Producing a 64-character hex digest, it carries 128 bits of collision-resistance strength according to NIST's hash-function guidance:² no practical technique can make two different real files share the same SHA-256 output. Because both NIST and major OS vendors treat it as the current standard, SHA-256 is the hash to match whenever a publisher lists multiple algorithm options alongside a download.

When to choose SHA-512

For large files on 64-bit hardware, SHA-512 often computes faster than SHA-256 because its internal operations align naturally with 64-bit CPU registers.³ It uses a 512-bit internal state and produces a 128-character hex digest, which gives it a wider security margin than SHA-256.⁴ Both algorithms remain unbroken for all practical purposes, so choosing between them comes down to what the publisher provided: match the algorithm they listed rather than switching to a different one on your own.²

A concrete digest makes the concept tangible. A file containing exactly the five bytes hello, with no trailing newline, hashes to SHA-256 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Add, remove, or change a single character and every one of those 64 hex digits shifts, which is the avalanche effect that makes a checksum match meaningful in the first place.

Why MD5 is legacy

Through the 1990s and early 2000s, MD5 was the dominant checksum algorithm for software distribution. Researchers broke it cryptographically in 2004 by demonstrating that two different files can be deliberately crafted to produce the same MD5 hash.⁵ That collision capability means an attacker can substitute a malicious file that passes an MD5 check, so MD5 provides no protection against an adversary who controls the download source.

MD5 still catches accidental corruption reliably: a damaged download will produce a different hash in nearly every case.⁵ It is not safe for security-critical verification where an active attacker is a concern, because a determined adversary can craft a valid-looking MD5 match. If the publisher offers SHA-256 or SHA-512 alongside MD5, always use the stronger option.

When older hashes still appear

Like MD5 but through a different class of attack, SHA-1 lost its security guarantees when researchers from Google and CWI Amsterdam demonstrated a practical collision in 2017, an event known as SHAttered.⁶ Older package mirrors and legacy build pipelines still produce SHA-1 checksums, but no new infrastructure should rely on them for security verification. Treat a SHA-1 match the same way you treat an MD5 match: it confirms the download was not accidentally corrupted, but does not protect against deliberate substitution by an attacker.

Large file support

This tool processes files in 2 MB chunks, feeding each chunk to all four hash algorithms simultaneously so every digest finishes at the same time. Only one chunk is held in memory at any point, which means multi-gigabyte ISO images and firmware dumps verify without exhausting browser memory, regardless of how large the file is.

What affects hashing speed

The hashing engine runs on the main browser thread and yields control between chunks, so the page stays responsive during long computations. Actual completion time depends on storage speed, browser overhead, and the selected algorithms. Because the browser File API reads only files the user explicitly selects, you can verify sensitive payloads like firmware images, medical device software, or security tool downloads without passing them through a third-party service.⁷

Checksums, signatures, and the chain of trust

A checksum proves that a file's contents are intact, but it does not prove the file came from the actual publisher. Both the binary and its posted checksum live on the same server, so a compromised download origin or CDN can swap them out together and the hash would still match the tampered file.

For most personal downloads over HTTPS from the publisher's own domain, a matching SHA-256 hash is sufficient because the TLS connection already authenticates the server.⁸ Fetching the checksum from a different location than the file itself, such as a GitHub release page while downloading the binary from a mirror, partially reduces this risk: an attacker would need to compromise both locations simultaneously, and GitHub release assets expose SHA-256 digests through the REST API.⁹

Adding a GPG signature

GPG signatures add the authenticity layer that checksums alone cannot provide. When a publisher signs a release, they use a private key that only they hold to sign the checksum file; you verify the signature against their published public key, and a valid result confirms two things at once: the file is unmodified and it was signed by whoever holds that private key.¹⁰

Linux distributions commonly publish checksums in files such as SHA256SUMS or CHECKSUMS in the same directory as the ISO image.¹¹¹² Fedora signs its CHECKSUM file before verification.¹⁰ For production deployments or security-critical tools, treating a checksum match as the first step and a GPG signature verification as the second is the professional standard.

Where publishers post checksums

Knowing where publishers post checksums saves the search time before you can verify anything. GitHub releases pages list SHA-256 digests in the release notes or as separate .sha256 files attached to the release. Popular Linux distributions post checksums in a file typically named SHA256SUMS or CHECKSUMS in the same directory as the ISO image.

GitHub release assets make expected checksums available alongside downloads.⁹ Linux distribution mirrors also publish checksums in the same directory as the ISO image.¹¹¹² CapyToolkit's hash verifier handles the computation side for these workflows: drop the downloaded file onto the tool, paste the expected hash from the publisher's page into the Compare field, and a green match badge confirms the download is exactly what the publisher released.