desktest.net
GitHub

File Hash Check Guide

A reference for the desktest.net File Hash Check. It computes a file's SHA-256, SHA-1, and SHA-512 in your browser and compares them against a hash a vendor published, so you can confirm a downloaded driver or installer is the exact file the vendor released and was not corrupted or tampered with on the way to you. The file never leaves your machine.

Open the File Hash Check ->

What does File Hash Check do?

A cryptographic hash is a fixed-length fingerprint of a file. Change a single byte anywhere in the file and the hash changes completely. Vendors publish the hash of each release next to the download so you can confirm the copy you received is byte-for-byte identical to the copy they built.

This tool reads the file you choose or drop, and computes three hashes locally with the browser's built-in Web Crypto API:

Paste the vendor's published hash into the compare box and the tool checks it, case-insensitively, against all three. If it equals any of them you get a green MATCH; if it equals none you get a red NO MATCH.

Nothing is uploaded. The file is read into the browser tab and hashed on your machine. There are no network calls on the page, so it is safe to hash confidential files. View the page source to confirm.

How to verify a download against a vendor's hash

The typical case: you downloaded a driver, a firmware image, or an installer, and the vendor's download page lists a SHA-256 checksum next to it. Here is the full flow.

  1. Find the vendor's published hash. On the official download page look for a value labelled SHA-256, SHA256, or "checksum". It may be on the page itself, in a linked .sha256 or SHA256SUMS file, or in the release notes. Copy it. Only trust a hash served over HTTPS from the vendor's own site, never one that arrived in the same email as the file.
  2. Open the File Hash Check. Go to the tool.
  3. Load the file you downloaded. Drag it onto the drop zone, or click Browse for a file and pick it. Hashing starts immediately and shows a "hashing" state for large files.
  4. Paste the vendor's hash into the compare box. A label prefix such as sha256: and any surrounding whitespace are ignored, so you can paste straight from a checksums file.
  5. Read the result. Green MATCH means the file is exactly what the vendor released. Red NO MATCH means it is not - stop and do not run it.
A hash proves the file is identical to what the vendor published. It does not prove the vendor is trustworthy or the software is safe. Verify the file is intact, and separately decide whether the source deserves your trust.

Reading the results

After a file is hashed the tool shows three panels.

The File panel shows the name, size (human-readable and exact byte count), and the MIME type the browser reported. Check the byte count against what the vendor lists; a wildly different size is an early sign you have the wrong file.

The Computed hashes panel lists SHA-256, SHA-1, and SHA-512 as lowercase hexadecimal. Each has a Copy button. When a pasted hash matches one of them, that row is highlighted green.

The Compare panel is where you paste the expected hash. The result updates as you type: a grey prompt before you paste anything, a green MATCH when your hash equals any computed hash, or a red NO MATCH with the warning that the file does not match the expected hash and should not be trusted.

The verdict panel at the top summarises the outcome with a plain next step. Copy Diagnostic Report copies a plain-text record - file name, size, all three hashes, the expected hash, and the compare result - to paste into a ticket or an email.

Why it matters: tampered downloads and supply chain

Checking a hash defends against two different problems.

Corruption. A download interrupted by a flaky connection, a full disk, or a proxy that mangled the bytes produces a file that will not install cleanly or will crash later. The hash catches this instantly, before you waste time on a broken install.

Tampering and supply-chain attacks. This is the security case. Attackers have repeatedly swapped legitimate installers for trojaned versions - by compromising a mirror or CDN, by hijacking a download link, or by a man-in-the-middle on the network path. A user who runs the swapped installer hands the attacker whatever privileges the installer requests, which for a driver or system tool is usually everything. If the vendor published the hash on a channel the attacker did not also control, comparing it catches the substitution: the tampered file's hash will not match.

This is exactly why the comparison hash must come from a trustworthy place. A hash sitting in the same compromised mirror as the file, or in the same phishing email, proves nothing - the attacker could regenerate it. Get the hash from the vendor's HTTPS site, their signed release notes, or an official package index.

For the strongest guarantee, prefer a vendor's code signature (Authenticode on Windows, notarization on macOS, GPG-signed checksums for open-source releases) over a bare hash. A signature binds the file to the vendor's key; a bare hash only proves the file matches a value you obtained separately. A hash check is the fast, universal first line; a signature is the stronger second line where one exists.

SHA-256 vs SHA-1 vs MD5

Not all hash algorithms are equally safe. The difference that matters here is collision resistance: whether an attacker can craft two different files with the same hash. If they can, the hash can no longer prove a file was not swapped.

AlgorithmStatus for securityUse it for
SHA-256 / SHA-512Strong. No practical collision attacks. This is the current standard.Verifying downloads, anything security-sensitive.
SHA-1Broken. Practical collisions were demonstrated in 2017. Do not rely on it to prove a file was not tampered with.Legacy comparison only, when a vendor still lists only a SHA-1 checksum.
MD5Badly broken. Collisions are trivial to generate. Not offered by this tool.At most a corruption check against a legacy source. Never for security.

The tool shows SHA-1 for legacy comparison because some older vendor pages still publish only a SHA-1 value, and matching it is better than nothing for catching accidental corruption. But if a vendor offers a SHA-256, always compare against that instead.

MD5 is deliberately not available. The browser's Web Crypto API (crypto.subtle.digest) does not implement MD5 at all, and there is no reason to add it: MD5 collisions can be produced on a laptop, so a matching MD5 does not prove a file was not tampered with. If a vendor publishes only an MD5, treat it as a corruption check at best and ask them for a SHA-256. SHA-256 is the modern standard.

For IT admins

Hash verification belongs in any process where a binary is downloaded and then run with elevated rights: driver rollouts, firmware updates, imaging tools, and third-party installers deployed through your management stack.

Elsewhere on the web: