# File Checksum — AO tool > Check that a download arrived intact — MD5, SHA-1 or SHA-256, on a file of any size. Runs entirely client-side: no upload, no server, no file limits, no sign-up. Human page: https://abstractobjective.dev/tools/file-hash/ Status: live · Category: files ## Input and output - In: * - Out: checksum text file ## Programmatic use (the AI-facing twin) All computation happens locally in the page context. - `window.AOHash.hashBlob(blob, algorithm, onProgress?) -> Promise` Hash a Blob or File of any size. algorithm: md5|sha1|sha256. Reads in 4MB slices so peak memory is the slice, not the file. Returns a lowercase hex digest. - `window.AOHash.hashAll(blob, algorithms?) -> Promise<{md5, sha1, sha256}>` Compute several digests for the same Blob in one call. - `window.AOHash.extractDigest(text) -> string` Pull a digest out of pasted text in any common published format — a bare hash, sha256sum output, or "SHA256 = ..." — by taking the longest hex run. ## Notes - Any file size: the file is streamed past the hasher in 4MB slices and each slice is released, so a 20GB image is no harder than a 20MB one. - The hash implementations are AO's own (engine/hash.mjs), verified against the published test vectors in RFC 1321, RFC 3174 and FIPS 180-4, and cross-checked against Node's crypto on a megabyte of data. - The browser's built-in crypto cannot do this: SubtleCrypto.digest() takes the entire input at once, with no incremental update, so it would require holding the whole file in memory. - MD5 and SHA-1 are offered because published checksums still use them, but neither should be relied on against a deliberate attacker — both are broken for collision resistance. ## Properties - Privacy: files never leave the browser tab. - Limits: none imposed by us; the practical ceiling is your device's memory. - Cost model: client-side compute — free without caps, sustainably. --- ## What a checksum is for When you download something important — an operating system image, a database backup, a signed release — the publisher usually prints a long string of hex next to the link. That string is a fingerprint of the exact bytes they intended you to receive. Run the same calculation on the file you actually got. If the two strings match, your copy is identical, down to the last bit. If they differ by a single character, something changed on the way: a truncated download, a failing disk, a corrupted mirror, or occasionally something worse. Paste the published checksum into the box above and this page will tell you **MATCH** or **DOES NOT MATCH** rather than making you compare 64 characters by eye — which is exactly the step where people miss the one that differs. ## Why this one has no size limit Every checksum tool that runs on a server must cap the upload, because you would be sending them the whole file. A 5 GB disk image means 5 GB of their bandwidth in, before any work begins. That cost is why the free tiers stop at a few hundred megabytes. Here the file never moves. It is read from your disk in small slices, each slice folded into the running calculation and then released, so the memory in use stays roughly the size of a slice no matter how large the file is. A 20 GB image is no harder than a 20 MB one — it just takes longer to read. Your browser's built-in cryptography cannot do this, which is worth knowing: its `digest()` function takes the entire input in one go, with no way to feed it progressively. So the hash implementations here are our own, written to work in pieces. **The honest trade:** hand-written JavaScript is slower than the native code your operating system would use. Measured here, it runs at roughly **7 MB per second** — so a 700 MB file takes about a minute and a half, and a 4 GB disk image around ten minutes. For a one-off verification of a download that itself took longer than that to arrive, this is usually fine. If you are checking very large files regularly, your system's own `sha256sum` or `certutil` will be far quicker; this tool exists for the times you want an answer without installing anything or handing the file to a stranger. ## Are they correct? That is the right question to ask about hand-written cryptographic code, and it has a checkable answer: **the published test vectors**. MD5 has an official suite in RFC 1321, SHA-1 in RFC 3174, SHA-256 in FIPS 180-4. All of them pass. They are additionally cross-checked against an independent implementation on a megabyte of data, at every awkward length around the 64-byte block boundary where padding bugs traditionally hide, and in every chunk size from one byte upward — because a streaming hash that disagreed with itself depending on how the file happened to be sliced would be worse than useless. ## Which algorithm **SHA-256** is the default and the right choice for anything current. **SHA-1** and **MD5** are here because a great deal of published material still lists them, and you need to be able to check what you were actually given. Both are broken for collision resistance — it is practical for someone to construct two different files with the same MD5 or SHA-1. They remain fine for catching accidental corruption, which is what most checksums are used for, but they prove nothing against a deliberate attacker. If you are verifying something security-critical and have the choice, use SHA-256.