Your files never leave your device. All processing happens locally in your browser.
How do I compute and verify a file’s checksum in the browser?
Drop a file (or paste text) and this tool computes MD5, SHA-1, SHA-256/384/512, SHA-3 and CRC32 at once — SHA-2 via the browser’s native Web Crypto and MD5/CRC32/SHA-3 via inlined WebAssembly. Files stream in 8 MiB chunks with a progress bar, so multi-gigabyte files work without freezing. To verify, paste an expected checksum: the tool auto-detects the algorithm by length and shows a clear MATCH / NO-MATCH. Everything runs locally; nothing is uploaded.
MD5, SHA-1, SHA-256/384/512, SHA-3 and CRC32 — computed all at once, lowercase hex
SHA-2 uses native Web Crypto (FIPS 180-4); MD5/CRC32/SHA-3 use hash-wasm (WebAssembly)
Files stream in 8 MiB chunks with a live progress bar — gigabyte files never load fully into memory
Verify mode auto-detects the algorithm by length and compares with a constant-time-style check
MD5 and SHA-1 are broken — use them for integrity only; prefer SHA-256+ for security
What is
Checksum (cryptographic hash / file digest)
A checksum is a fixed-length fingerprint computed from a file or message by a hash function: the same input always yields the same digest, and even a one-bit change produces a completely different value, so matching two checksums confirms the bytes are identical. Cryptographic hashes (SHA-256, SHA-512, SHA-3) additionally resist an attacker crafting a second file with the same digest; older functions (MD5, SHA-1) are broken and suitable only for accidental-corruption checks, while CRC32 is a non-cryptographic error-detection code. This tool computes and verifies checksums entirely in your browser with the Web Crypto API and inlined WebAssembly.
No. The file is read and hashed entirely in your browser and never leaves your device.
The tool is 100% client-side. Your file is read locally with the browser’s File API and streamed in 8 MiB chunks into the native Web Crypto API and an inlined WebAssembly hasher — there is no upload, no server, no CDN in the processing path and no telemetry. Because the file is sliced and hashed incrementally, even a multi-gigabyte ISO is processed without loading it fully into memory or freezing the tab, and nothing is logged or stored: close the tab and it is gone. The only optional network use anywhere on the site is consent-gated ads, which never see your data. Uploading a file to a remote hashing service means trusting it not to keep a copy; here, by construction, the bytes never leave.
Use SHA-256 (or higher) for anything security-relevant; MD5 and SHA-1 are broken and fit only for detecting accidental corruption.
MD5 (RFC 1321) and SHA-1 both have practical collision attacks — the 2017 SHAttered work produced two different PDFs with the same SHA-1 digest — so a matching MD5 or SHA-1 proves a file was not <em>accidentally</em> corrupted, but not that it was not <em>deliberately</em> tampered with. CRC32 is weaker still: it is an error-detection code, not a cryptographic hash, and is trivially forgeable. For verifying downloads, signatures or anything an attacker might target, use SHA-256, SHA-512 or SHA-3, which have no known practical collisions. Many projects still publish MD5/SHA-1 sums for legacy reasons, so this tool computes them too — just treat a match as an integrity check, not a security guarantee.
It auto-detects the likely algorithm from the checksum’s length, then compares it against every digest it computed.
A hex checksum’s length reveals its algorithm: 8 characters is CRC32, 32 is MD5, 40 is SHA-1, 64 is SHA-256 or SHA3-256, 96 is SHA-384, and 128 is SHA-512 or SHA3-512. When you paste an expected value the tool cleans it (trims spaces, drops a leading 0x, lower-cases it), shows the likely algorithm(s) for that length, then compares it byte-for-byte against every digest of every file or the text input — telling you exactly which file and algorithm matched. The comparison is case-insensitive and uses a constant-time-style XOR-accumulate with no early exit, so its timing does not leak how many leading characters matched.
Length only hints at the algorithm; the match is confirmed by comparing the actual digest bytes, so a false positive is astronomically unlikely.
SHA-256 and SHA3-256 both produce 64 hex characters, and SHA-512 and SHA3-512 both produce 128, so length alone cannot tell them apart — that is why the tool shows the detected length as a <em>hint</em> and then verifies by comparing the full digest value, not just the length. If your pasted checksum equals a computed digest, the two files are the same with overwhelming confidence (guessing a 256-bit digest by chance is about one in 10⁷⁷). If it does not match, either the file differs from the one the checksum was made for, or you need to enable the specific algorithm the checksum came from — the tool prompts you to do exactly that.
Detailed Explanation
📖How It Works
What the Checksum Verifier Does
The Checksum Verifier is a 100% client-side tool that computes and verifies file and text checksums. The user drops one or more files (or pastes UTF-8 / raw-hex text) and the tool computes MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512 and CRC32 in a single pass, showing each digest as lowercase hex with a per-row copy button. To verify a download, the user pastes an expected checksum: the tool auto-detects the likely algorithm from its length and shows a clear MATCH or NO-MATCH against every computed digest, naming the exact file and algorithm that matched. Files and text are hashed entirely in the browser and are never uploaded.
Computes MD5, SHA-1, SHA-256/384/512, SHA3-256/512 and CRC32 at once
Drop multiple files or paste UTF-8 / hex text; lowercase-hex output, per-row copy
Verify mode auto-detects the algorithm by length and shows MATCH / NO-MATCH
Downloads a coreutils-style sums.txt for use with sha256sum -c and friends
MD5 and SHA-1 are flagged as broken — integrity only, not security
⚙️Methodology
How the Hashes Are Computed
Two real cryptographic back-ends run locally. The SHA-2 family (SHA-1, SHA-256, SHA-384, SHA-512, per FIPS 180-4) is computed with the browser’s native Web Crypto API, crypto.subtle.digest — the same audited implementation used for TLS. Everything Web Crypto lacks — MD5 (RFC 1321), CRC32 (ISO 3309 / IEEE 802.3) and SHA-3 / Keccak (FIPS 202) — is computed with hash-wasm, a hand-tuned WebAssembly library whose wasm is inlined into the bundle, so there is no runtime CDN fetch. Files are streamed: the tool reads the file in 8 MiB slices and feeds each chunk into an incremental init()/update()/digest() hasher, so memory stays flat and a live progress bar tracks bytes processed. That lets a multi-gigabyte ISO be hashed without ever loading it fully into memory or freezing the tab, and toggling on an extra algorithm only computes the digests a file is still missing.
SHA-1/256/384/512 via native Web Crypto crypto.subtle.digest (FIPS 180-4)
MD5, CRC32 and SHA-3 via hash-wasm WebAssembly (wasm inlined, no CDN fetch)
Files streamed in 8 MiB chunks through an incremental hasher — flat memory
Live progress bar reports bytes processed; the tab stays responsive
Enabling a new algorithm re-hashes only the missing digests, not the whole file
📋Use Cases
Verifying a Download the Right Way
A hex checksum’s length reveals its algorithm: 8 characters is CRC32, 32 is MD5, 40 is SHA-1, 64 is SHA-256 or SHA3-256, 96 is SHA-384, and 128 is SHA-512 or SHA3-512. When an expected value is pasted, the tool cleans it (trims whitespace, drops a leading 0x, lower-cases it), shows the likely algorithm(s) for that length, then compares it byte-for-byte against every computed digest — the length is only a hint, the match is confirmed on the actual bytes. Crucially, a checksum only proves integrity relative to a value you already trust: downloading a file and its checksum from the same server proves nothing if that server is compromised. The expected hash should come from an independent, trusted channel — the vendor’s signed release page, a GPG-signed SHA256SUMS file, or a second mirror — and only then compared here.
Length maps to algorithm: 32=MD5, 40=SHA-1, 64=SHA-256, 128=SHA-512
Pasted value is trimmed, 0x-stripped and lower-cased before comparison
Match is confirmed on the digest bytes, not just the length hint
Get the expected hash from a trusted, independent channel
A GPG signature on the checksum file adds authenticity a hash alone cannot
⚠️Limitations
Honest Limitations
MD5 and SHA-1 are cryptographically broken: practical collision attacks exist (the 2017 SHAttered work produced two different PDFs with the same SHA-1 digest, and MD5 collisions were weaponised to forge a certificate authority in 2008). A matching MD5 or SHA-1 therefore proves a file was not accidentally corrupted, but not that it was not deliberately tampered with — for that, use SHA-256 or above. CRC32 is not a cryptographic hash at all; it is an error-detection code and is trivially forgeable. A checksum also proves only integrity, never authenticity: it says the bytes are unchanged relative to a reference value, not who produced them — that requires a digital signature. Finally, the verify comparison is constant-time-style (an XOR-accumulate with no early exit) but JavaScript cannot guarantee true constant time and the length is checked first; that is appropriate for a client-side integrity aid, not a substitute for a hardened server-side check. This tool is an aid, not a guarantee.
MD5 and SHA-1 have practical collisions — integrity only, never security
CRC32 is error-detection, not a cryptographic hash; trivially forgeable
A checksum proves integrity, not authenticity — a signature proves the author
Trust is only as good as the source of the expected hash
Constant-time-style compare — best-effort in JS, not a hardened check
🔒Privacy & Security
Private by Design
Everything happens on your device. Files are read with the browser’s File API and hashed by the native Web Crypto API and an inlined WebAssembly hasher — there is no network request, no upload, no logging, no server and no CDN in the processing path. Because files are sliced and hashed in 8 MiB chunks, nothing needs to be buffered or retained, and nothing is persisted or added to history; close the tab and every digest is gone. The tool works offline once cached, supports dark mode and a mobile-first layout, and the only optional network use anywhere on the site is consent-gated ads, which never see your files or text. This matters because the files you verify — installers, backups, private documents, key material — are exactly the things you would never want to round-trip through a remote hashing service.
Files and text hashed locally by Web Crypto + inlined WebAssembly
No server, no CDN, no upload, no logging, no telemetry, no account
Chunked streaming means nothing is buffered or persisted
Works offline once cached; dark-mode and mobile-first
Your installers, backups and documents never leave the machine
Checksum algorithms compared
Algorithm
Digest size
Cryptographically secure?
Best for
CRC32
32-bit (8 hex)
No (not a hash)
Fast accidental-corruption checks only
MD5
128-bit (32 hex)
No — broken (collisions)
Legacy integrity, dedup, matching old checksums
SHA-1
160-bit (40 hex)
No — broken (SHAttered 2017)
Legacy integrity and Git object IDs
SHA-256
256-bit (64 hex)
Yes — recommended
Verifying downloads, signatures, general security
SHA-512
512-bit (128 hex)
Yes
Higher margin; faster than SHA-256 on 64-bit CPUs
SHA3-256
256-bit (64 hex)
Yes (different design)
A Keccak-based alternative to SHA-2
Prefer SHA-256 or above for anything security-relevant; MD5, SHA-1 and CRC32 are for accidental-corruption checks only. Everything in this tool runs locally in the browser; nothing is uploaded. As of July 2026.
