Security Runs locally Ready to use Built-in examples No tracking

File Hash Checker

Pick a file (up to 20 MB) and get all three digests at once, or switch to text mode and paste content. Compare the values with the ones published by the vendor to confirm the download is intact and unmodified.

After downloading an installer, an image or an archive a colleague sent, the first step is checking the hash: matching it against the value published by the vendor, or passed along with the file, confirms the download is complete and was not substituted. This tool reads the file in the browser (up to 20 MB) and returns MD5, SHA-1 and SHA-256 at once, covering publishers who list only one of the three.

Which value to compare depends on the question being asked: for a corrupted download any of the three will do, but detecting a deliberate substitution requires SHA-256, since MD5 and SHA-1 are both demonstrably open to constructed collisions. Files over 20 MB, or a batch of them, are faster handled with a system command — sha256sum on Linux and macOS, or certutil on Windows — which streams the file instead of holding it in memory.

—

How to use

  1. Choose the file, up to 20 MB, or switch to text mode.
  2. Read the MD5, SHA-1 and SHA-256 values.
  3. Compare against the value the publisher provided, in the same format.
  4. Use SHA-256 for substitution checks, and a system command for large or bulk files.

How it works

Basic usage

Switch the target to "file" and pick a local file — results appear automatically: the main result is MD5 (32 lowercase hex), with SHA-1 and SHA-256 on the lines below. Switching to "text" and pasting content computes the same three digests over the UTF-8 encoding, handy for cross-checking server logs.

Which of the three digests to use

For "is my download corrupted?" any of them works; for "was this file swapped?" you must use SHA-256 — MD5 and SHA-1 both have proven constructions producing a different file with the same digest, while SHA-256 has no practical collision. All three are shown at once for when the other side publishes only one of them.

Why big files belong on the command line

Browser hashing is single-thread bound: beyond about 20 MB it stutters visibly (especially computing all three at once), hence the tool's 20 MB cap. Larger files should use system commands — sha256sum on Linux/macOS, certutil -hashfile on Windows — which stream and ignore memory limits.

Method: MD5 per RFC 1321, SHA-1 per RFC 3174 and SHA-256 per FIPS 180-4, all implemented in pure JavaScript and computed synchronously over bytes (the raw bytes of a file, or the UTF-8 bytes of text). One run is limited to 20 MB — anything larger is rejected with a suggestion to use the command line, as there is no chunked incremental mode.

Code example

Shell The command on three platforms 

# Linux
sha256sum file.zip
md5sum file.zip

# macOS
shasum -a 256 file.zip

# Windows (cmd)
certutil -hashfile file.zip SHA256
certutil -hashfile file.zip MD5

PowerShell Windows PowerShell 

# Hashes in a single command; the result is uppercase hex
Get-FileHash file.zip -Algorithm SHA256
Get-FileHash file.zip -Algorithm MD5

# Batch-verify every file in a directory
Get-ChildItem *.zip | Get-FileHash -Algorithm SHA256

FAQ

Is this MD5 the same as the "MD5 tool"'s output?

Yes — same implementation, same content, same digest. The difference is packaging: this tool gives all three algorithms at once and reads files directly, while the MD5 tool focuses on the uppercase form and the 16-character short form.

Why doesn't my file's hash match the official value?

Check, in order of likelihood: incomplete download (retry or switch mirrors), wrong version being compared, comparing a SHA-1 value against MD5, missing characters at the copy's ends, or download managers that modify file tails. For archives, confirm the official hash covers the archive itself, not the extracted files.

Does a matching hash prove the file is safe?

It proves "what you got matches what the publisher published" — provided the hash itself came from a trusted channel (the official HTTPS page or announcement). If someone forwarded the hash, or the publisher's site was compromised, a match says nothing about safety: it verifies integrity, not trustworthiness of the source.

Why use the command line for large files instead of a web page?

Browser hashing loads the whole file into memory and computes on the main thread — past 20 MB it stutters or freezes. System tools like sha256sum (Linux/macOS) or certutil -hashfile (Windows) stream the data with almost no memory footprint, hashing gigabytes in seconds.

Will the selected file be uploaded to a server?

No. The browser's FileReader reads the bytes locally and feeds them straight into the computation — zero network requests, and the server never sees the content. Verify in DevTools' network panel after choosing a file: no upload appears.

Why does the archive's hash differ from the files inside it?

An archive is a container: beyond file contents it holds names, directory structure, compression metadata and checksums — any change shifts the whole package's digest. Official hashes therefore cover the archive itself; hashing the extracted files naturally mismatches.

Does hashing the same content twice give the same result?

Always. Hashing is a pure function: identical bytes yield identical digests across browsers and operating systems. Only the content changes the result — one extra space, LF becoming CRLF, or UTF-8 becoming GBK produces a completely different digest.

How is the byte count computed in text mode?

By UTF-8 encoding: a half-width character is 1 byte, a Chinese character typically 3, an emoji 4. That byte count is exactly the data length fed into the digest — comparing it alongside the digest quickly reveals "we hashed different things".