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 is especially important for security-sensitive files: a tampered installer could silently backdoor a system, and a corrupted firmware image could brick a device. Checking the hash before running or flashing takes seconds and eliminates both risks.
SHA-256: the current standard
SHA-256 is the algorithm NIST recommends, and virtually every modern software publisher, package manager, and operating system uses it to publish checksums. Producing a 64-character hex digest, it encodes enough entropy that no practical collision has ever been demonstrated: no known 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.
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.
TIP Most Linux distribution download pages list SHA-256 checksums. Copy the published digest, hash your downloaded ISO with this tool, and paste it into the Compare field.
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.
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. Only one chunk is held in memory at a time, so the tool handles multi-gigabyte ISO images and firmware dumps without exhausting browser memory, regardless of file size.
The hashing engine runs on the main browser thread and yields control between chunks, so the page stays responsive during long computations. On a modern laptop SSD, a 4 GB file typically completes in under 30 seconds; on slower external drives that time extends proportionally, but the engine processes data at the drive's own read speed without adding overhead. Because the file never leaves your machine, you can verify sensitive payloads like firmware images, medical device software, or security tool downloads that should never pass through a third-party service.
NOTE The file is read directly from your local storage and is never uploaded or transmitted. This tool works entirely offline once the page has loaded.
Checksums, signatures, and the chain of trust
A checksum proves that a file's contents are intact but does not prove the file came from the actual publisher. Both the file and its posted checksum can be replaced at the same time if an attacker compromises the download server or its CDN origin.
Fetching the checksum from a different location than the file itself, such as the publisher's GitHub release page while downloading the binary from a mirror, partially reduces this risk: an attacker would need to compromise both locations simultaneously. 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.
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 ship with this model as standard practice. Debian, Fedora, and Arch all provide GPG-signed release manifests alongside their ISO SHA-256 checksums, and their package managers verify signatures automatically before applying any update. 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.
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.
Node.js, Python, and Go official download pages each list SHA-256 checksums next to every binary. CapyToolkit's hash verifier handles the computation side for all of 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.
