File Hash Checker

How does the tool verify file integrity?

A cryptographic hash function maps any input — whether 12 bytes or 12 gigabytes — to a short, fixed-length hex value. Change a single byte in the input and the hash, with overwhelming probability, changes completely. That’s what makes hashes the standard mechanism for file integrity: a publisher publishes the hash of a file, you compute it locally after downloading, and if both values agree, the file is unchanged since publication.

We compute via an incremental WASM-accelerated hashing layer running in the browser. Incremental means the file is not fully loaded into RAM — instead it is read in 64 KB chunks via File.stream() and fed piece by piece into the hasher. Only at the end does a single hex value emerge. This pipeline is exactly what allows files larger than 2 GB — the standard browser hashing API can’t manage that.

What do SHA-256, SHA-512, MD5, SHA-1, and BLAKE3 mean?

SHA-2 is the family of cryptographic hash functions specified by the US NIST in standard FIPS 180-4. SHA-256 produces a 256-bit digest (64 hex characters) and is today the de-facto standard for software releases, Linux ISO downloads, container images, and blockchains. SHA-512 is the longer variant with a 512-bit digest (128 hex characters) — same mathematical structure, larger output space.

SHA-1 (160 bits, 40 hex characters) and MD5 (128 bits, 32 hex characters) are older. MD5 was declared cryptographically broken in 2004, SHA-1 in 2017. For pure integrity checks (Git objects, cache keys, file versioning) both are still acceptable; for security-relevant verification — anywhere an attacker would need to be unable to produce a different file with the same hash — they are no longer recommended.

BLAKE3 is a modern hash standard from 2020. It produces a 256-bit digest like SHA-256, but is significantly faster, cryptographically secure, and parallelisable. Adoption is growing in build tools and content-addressable stores. It is not yet a de-facto distributor standard, but it is relevant — we offer it for those who need it.

When is each algorithm the right choice?

When a publisher provides a single hash without specifying the algorithm, infer from the hex length: 32 characters mean MD5, 40 mean SHA-1, 64 mean SHA-256 (or less commonly BLAKE3 — a sidecar file or distributor note usually clarifies), 128 mean SHA-512. The tool detects the length automatically and picks the matching algorithm; for 64-character inputs a SHA-256 / BLAKE3 toggle appears because both map to 64 characters.

For Generate the recommendation is pragmatic: SHA-256 is sufficient everywhere for modern integrity verification. If you have audit-compliance constraints or work with government workflows, add SHA-512. BLAKE3 is worth it when the receiving side actually understands BLAKE3 (otherwise the faster value is useless). MD5 and SHA-1 we generate only when the receiving side explicitly demands them — older CI pipelines or legacy manifest formats.

Hashing several algorithms at once costs only ~5–15 % extra time per algorithm because the file bytes only traverse the disk/memory path once — useful when you’re not sure which algorithm the recipient expects.

What’s the difference between Generate, Verify, and Compare?

Generate is the “I need new hash values” mode. One or more files in, all selected algorithms computed in parallel, the result is a per-file table. Useful for distributor manifest creation, backup audit lists, or simply to obtain a SHA-256 for your own file. The CSV export writes the table in a format Excel opens directly.

Verify is the “does this file match this expected hash?” mode. One file plus an expected value (pasted or via sidecar drop) — the tool computes, compares, and shows a match banner or a mismatch banner with diff highlighting. This is exactly the use case behind the term ‘file hash checker’ and the one most other tools either bury or skip entirely.

Compare is the “are these two files actually identical?” mode. Two files in, both hashed in parallel for all selected algorithms, the result is a banner (‘Identical files’ or ‘Files differ’) plus a per-algorithm table. Useful after backup restores, re-downloads, drive migrations, or cloud-sync comparisons.

Why do these big files work here when they fail elsewhere?

The standard browser hashing API expects the entire file as a single in-memory object. On Firefox that API rejects inputs over 2 GB with a TypeError — documented in detail in open-source issue trackers, where backup tools or file synchronisers crash on large media files. Other browsers run into the same limit in different ways because every browser tab eventually hits its memory ceiling.

We sidestep this with a WebAssembly-based hasher that works incrementally: init() starts a fresh state, update(chunk) feeds the next file chunk, digest() finalises and returns the hex value. The read path uses File.stream().getReader(), a standard browser API that delivers file bytes as a stream rather than as one giant blob. As a result the memory footprint stays under ~100 MB regardless of whether the file is 100 MB or 100 GB.

What is the tool good for — and what is it not?

Good for: software download verification against published hashes, backup restore validation, distributor manifest generation, cloud-sync verification, a forensic helper for ‘is this really the file I had two weeks ago?’, quick audit lists for photo or video folders.

Not good for: authentication (that’s HMAC plus a key, not a file hash), password storage (that’s Argon2/bcrypt/scrypt), defence against a compromised publisher (see the disclaimer below), MD5 or SHA-1 as a sole security proof (no longer recommended for that role).

Important note about hash verification: A matching hash confirms only that the file is identical to the one the publisher hashed — it does not prove the publisher itself is trustworthy. Compare the hash against an independent source (release notes, signed announcement, package-manager metadata) rather than only the value shown next to the download link.

Which tools pair with this one?

From the kittokit ecosystem on file verification and data integrity:

• Hash Generator — hashes text rather than files. Useful for password snippets, JWT secret tests, or API hashes.
• JWT Decoder — decode JSON Web Tokens, useful when verifying signed tokens (complementary to file hashes).
• UUID Generator — produce unique IDs for your own manifest files or test-data sets.