What the File Hash Checker Does
The File Hash Checker computes SHA-1, SHA-256, and SHA-512 digests of an uploaded file in one pass. Choose a file with the upload control — the placeholder reads Upload a file to compute its hashes… — and the output panel prints all three digests at once, each labelled with its algorithm, plus an info line reporting the file's size in bytes. No options, no server upload: the reading and hashing happen entirely in your browser.
Computing all three algorithms simultaneously is the deliberate design. Published checksums for downloads are inconsistently specified — some projects publish SHA-256, older ones SHA-1, a few SHA-512 — and having all three on screen means any published value can be compared immediately, without re-running per algorithm. The multi-algorithm
Hash Generator offers the same three-way view for pasted text; this page is its file-backed counterpart.
One honest limitation shapes what this tool is for: it reads files as text. For text files — source code, configs, JSON, CSV, Markdown — that is exactly the file's bytes, and the digests match command-line tools exactly. For binary files (executables, images, archives), the text-reading step can alter the byte stream, so the digests may not match sha256sum and friends. Text-shaped files are fully supported; byte-exact binary verification is on the roadmap as plumbing work, and until then command-line tools remain the right instrument for binaries.
How the Hashing Works
The pipeline has two stages. First, the chosen file is read through the browser's File API; the tool requests its contents as text, and the resulting string is re-encoded to a UTF-8 byte buffer — the comment in the implementation calls this "for binary fidelity," but the honest description is that text-mode reading plus UTF-8 re-encoding is byte-faithful only when the file is valid UTF-8 text to begin with. Second, that buffer is passed to Web Crypto's digest three times — SHA-1, SHA-256, SHA-512 — and the three digests are rendered as labelled hex lines.
For a text file, the round trip is lossless: bytes → text → identical bytes, so the SHA-256 line matches what sha256sum file.txt prints, byte for byte. Where it diverges from command-line behaviour is the classic trio: files with byte-order marks (the BOM is text-invisible but bytes-real), CRLF line endings (preserved here — they are bytes like any other), and binary content (UTF-8 decoding mangles invalid byte sequences, changing what gets hashed). That trio is the complete list of ways this tool's digests can differ from a byte-exact reference on non-clean-UTF-8 input.
The three algorithms and their output widths are worth keeping straight while reading the panel: SHA-1 prints 40 hex characters, SHA-256 prints 64, SHA-512 prints 128. All three are computed over the identical byte buffer, so a difference between any two runs means the file changed between reads — the digests are as deterministic as the input is stable.
Privacy is structural rather than promised: the File API reads the file into the page's memory, Web Crypto digests it, and nothing — file, bytes, or digests — leaves the browser. No upload occurs at any point, which is the property that makes hashing sensitive documents here acceptable where uploading them would not be.
Using the File Hash Checker
- Step 1 — Choose the file. Click the upload control and select the file. Nothing is transmitted; the file is read into the page. The placeholder text reminds you what will happen.
- Step 2 — Read the three digests. The output lists
SHA-1: …, SHA-256: …, and SHA-512: … lines, with the byte count on the info line. All three describe the same content. - Step 3 — Compare against the published value. Match the algorithm the publisher used — SHA-256 is the modern default — and compare character by character, or paste both into the Hash Comparison Tool. Any difference means the bytes differ, however invisible.
- Step 4 — Mind the text-mode scope. For source files, configs, and documents, trust the digests as byte-exact. For binaries (installers, images, archives), treat these digests as indicative and verify byte-exact with command-line tools — the caveat exists so a mismatch sends you to the right instrument, not into a debugging spiral.
- Step 5 — Record the digest, not the file. For anything you will re-verify later — downloaded artifacts, config snapshots — the 64-character SHA-256 line is the permanent record. Re-hash the candidate file later and compare; the tool re-runs in seconds.
Common Use Cases
Verifying text downloads against published checksums. Source archives, package tarballs with text payloads, license files, datasets in CSV or JSON — hash, compare, done. This is the bread-and-butter integrity check, and the three-algorithm output covers however the publisher formatted theirs.
Config and snapshot evidence. Before and after a migration or an automated edit, hash the config file; the recorded digest is compact evidence of what changed (or did not) that survives log rotation and exceeds any diff's expressiveness.
Deduplication checks on documents. Two text files with identical digests are identical — a cheaper and more reliable comparison than any diff for large files, and the three-digest output leaves no algorithm ambiguity.
Pre-flight checks in browser-only environments. Locked-down machines without shell access still have a browser; this page provides checksum verification where sha256sum is unavailable.
Teaching hash behaviour with real files. Modify a file invisibly (add a trailing newline), re-hash, and watch all three digests transform — the avalanche property, demonstrated on your own document.
Worked Example
Create a file hello.txt containing exactly hello world — no trailing newline. Upload it, and the output panel reads:
SHA-1: 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
SHA-256: b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
SHA-512: 309ecc489c12d6eb4cc40f50c902f2b4d0ed77ee511a7c7a9bcd3ca86d4cd86f989dd35bc5ff499670da34255b45b0cfd830e81f605dcf7dc5542e93ae9cd76f
with an info line of 11 bytes. Every value matches the canonical digests — the same ones the text-based generators in this domain produce for the identical content, and the same ones command-line tools print for a newline-less file. That is the text-file case working exactly as it should.
Now the caveat demonstration: add a trailing newline (as most editors do) and re-upload. All three digests change completely, and the info line reads 12 bytes. Nothing about the hashing is fragile — the input genuinely changed. This is also why a digest mismatch with a downloaded file usually means "the file differs," not "the algorithm is broken": check the byte count first.
Finally the honest binary illustration: upload a small PNG. The digests will compute without error, but they will likely not match sha256sum's output for the same file — the text-reading step altered invalid-UTF-8 sequences on the way in. Text files, exact; binaries, indicative. That boundary is the tool's honest scope.
Tips and Common Mistakes
- Match the publisher's algorithm, not your preference. A SHA-1 published value cannot be checked against your SHA-256 line — the widths (40 vs 64 characters) make the mismatch obvious at a glance. All three are always printed precisely so any published format is comparable.
- Byte count before blame. When a digest disagrees with a reference, confirm the info line's byte count matches what the reference hashed. Encoding differences and invisible bytes account for most "wrong hash" reports.
- Text files exact, binaries indicative. The tool reads files as text. Clean UTF-8 text round-trips byte-exactly; binaries do not. For executables, images, and archives, command-line hashing is the byte-exact instrument.
- Line endings are preserved, BOMs are included. CRLF stays CRLF, and a leading BOM contributes its three bytes. Both are correct — they are bytes — but they explain differences against references that stripped them.
- The digests never leave the page. No upload occurs — the file is read by the browser locally. That is the property to verify in any tool before hashing something sensitive; here it holds by construction.
- Large files are bounded by browser memory. The file is read fully into memory before hashing. Multi-gigabyte files belong to command-line tools; text-shaped files up to tens of megabytes are comfortable.
Frequently Asked Questions
Why do my digests not match sha256sum for a binary file?
The tool reads files as text, and binary content contains byte sequences that are not valid UTF-8 — the decode-and-re-encode step alters them, changing the hashed bytes. For text files the round trip is lossless and digests match exactly; for binaries, command-line tools are the byte-exact reference. This scope is documented honestly rather than papered over, and byte-level file reading is the planned fix.Is my file uploaded anywhere?
No. The browser's File API reads the file into the page's memory, Web Crypto computes the digests, and nothing leaves your machine — no network request carries the file, its bytes, or the results. Closing the tab discards everything. That structural privacy is the reason to hash sensitive documents here rather than in any upload-based service.Which of the three digests should I record?
SHA-256 is the default answer — 64 hex characters, the modern interchange standard, and far beyond collision reach. Record SHA-512 as well when the artifact's lifetime is long or the documentation names it. SHA-1 is printed for compatibility with older published values, not for new records.Why is the SHA-1 line even here if SHA-1 is broken?
Because older published checksums are SHA-1, and verifying a download against one is a preimage check — confirming known content — which remains sound. The broken property (chosen-collision resistance) matters to signatures, not to download verification. Record new artifacts with SHA-256 or SHA-512.Can I hash multiple files at once?
One file per run — choose, hash, record, repeat. For bulk verification, command-line tools iterating a directory are the right shape; this page is the browser-only, single-file instrument.Related Tools