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.

Reading a checksums file into the Compare field

Open a checksums file and every line reads the same way: the hex digest, a separator, and the filename that digest belongs to.⁵ The digest is the only part the Compare field wants, so copy the hex string alone and leave the filename behind. The field treats whatever you paste as one whole value and matches it against all four computed digests, so a digest followed by its filename reads as a non-match even when every hex character is correct. Selecting the digest without the trailing filename is the one fiddly step, and taking it slowly beats re-downloading a file that only looked wrong.

Casing and spacing work in your favor. The field trims surrounding whitespace and lowercases whatever arrives, so an uppercase digest lifted from a printed spec sheet matches the lowercase digest rows without any manual conversion on your part, and stray spaces before or after the paste are equally harmless. What never matches is extra content trailing the digest: the filename from the checksums line, a stray label, or a digest written in a non-hex encoding. A paste that reads as a match badge is therefore a paste of the bare digest, in any casing, with nothing attached after the last hex character.

The same check from a terminal

The browser route has a terminal twin. Every desktop operating system ships a checksum utility, so the same verification runs with no web tool at all: Linux distributions and Raspberry Pi images use sha256sum,⁶ macOS carries shasum,⁷ and Windows provides Get-FileHash in PowerShell.⁸ Each utility prints the digest for a file you point it at, and checking that output against the publisher's published value performs exactly the verification the Compare field automates. The hash math is identical in both places; a SHA-256 digest computed in a terminal equals the same digest computed in this browser, and only the interface differs.

Each route earns its place. The browser wins for one-off checks on a machine you would rather not touch: nothing lands in shell history, no script needs writing, and dragging one file onto the page returns all four digests at once, which is exactly what you want when the publisher lists several algorithms and you are unsure which one to trust. The terminal wins on servers and in scripted pipelines, where the files already live beside a shell and a verification step belongs inside the deployment script rather than inside a tab you open by hand. Pick the route by where the file lives and how often the check repeats; the digest comes out the same either way.

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.¹¹

The input is the file, not the text

This verifier takes files and nothing else. The drop zone is the single input path, and no text box exists anywhere in the suite, so there is no way to type or paste content for hashing here. That boundary is deliberate. A digest computed over typed-in text answers a different question, the kind a developer asks when fingerprinting a string for a cache key or a short message for a signature, and that job belongs to a different kind of tool. Download verification needs the artifact on disk, byte for byte as the publisher shipped it, which is what the file picker hands over.

For this job, file-first is the honest shape. What you are verifying is the artifact on disk, and its exact bytes are what the publisher hashed in the first place, so any path that re-encodes the content on the way in would poison the comparison. Typed or pasted text goes through exactly that kind of transformation: an editor normalizes line endings, trims invisible whitespace, and may re-save with a different encoding, and each of those changes shifts every hex character of the digest. Dragging the downloaded file itself skips the transformation entirely, which is what makes a green match badge meaningful rather than coincidental.

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.

When the published digest is not hex

Some publishers write their digests in a different alphabet. Package-manager lockfiles and some registry metadata publish integrity digests encoded as base64 rather than as hex, and the value underneath is unchanged: it is the same digest over the same file bytes, only spelled with a 64-character alphabet instead of a 16-character one. That is why a base64 string looks shorter than its hex twin; the two notations pack the same bits with different density. Nothing about the file is different, and nothing about the algorithm changed, which is why the encoding question is purely a notation question.

Here that difference collides with the Compare field. The field matches the lowercase hex digests the tool computes, so a base64 string lifted from a lockfile never matches, even when the file on disk is byte-for-byte perfect and the digest underneath is exactly right. Convert the published value to hex before pasting, or find a hex digest published for the same artifact, and the match behaves exactly as this page describes. Until one of those happens, the field is answering a slightly different question than the one you asked, and a NO MATCH badge on a healthy file is the confusing result.