🔐 File Hash Calculator & Checker (SHA-256 / MD5 / SHA-1)

Drop a file into your browser to instantly compute MD5, SHA-1, and SHA-256. Perfect for detecting tampering and verifying integrity of downloaded files.

100% Free No signup Browser-only 5 languages Dark mode

✅ Verify against expected hash (Checker mode)

Paste the SHA-256 / MD5 / SHA-1 value from the vendor site. We compare it against the hash computed above and tell you instantly if the file matches. Mismatch = file is corrupted or tampered with.

Expected hash (any algorithm, case-insensitive)

If something is broken or not displaying correctly, let us know via the contact form — we use the feedback to improve.

Other Tools

Base64 Encode / Decode

Includes size overhead calculation

🔧

JSON Formatter

Format / validate / minify

File validation implementation checklist

Size, MIME type, magic bytes

File Signature (Magic Bytes) Reference

PNG, JPEG, PDF, ZIP and more

📖 Where people get stuck

Drop in a file and it computes MD5, SHA-1 and SHA-256 with the Web Crypto API; paste an expected value and it tells you whether they match. The file never leaves your browser. What you can establish here is only whether the bytes in your hands match the value that was published — a hash tells you nothing about whether the file is safe, nor about whether the published value itself is trustworthy. A hash is a tool for identity, not for legitimacy. Conflate the two and you end up feeling verified while having verified nothing.

Case	What happens	What to do
A matching hash does not prove the file was not tampered with	If the published hash sits on the same server as the download, both can be rewritten. An attacker in a position to swap the file is also in a position to swap the hash printed next to it — and because they match, your verification succeeds. What this arrangement protects against is only corruption in transit and picking up the wrong mirror; it does nothing about a download from a compromised server. Several open source projects have in fact had their distribution server breached and both the binary and the checksum replaced. "I checked the checksum" is not, on its own, a security claim.	Obtain the hash through a different channel from the file. If you are downloading from a mirror, take the hash from the upstream release notes or the GitHub Releases page. Verifying a signature is stronger still: GPG, minisign and operating-system code signing cannot be produced without the private key, so breaching a server is not enough to forge one — and it is one line, `gpg --verify file.sig file`. The open question then becomes where you got the key — fetch it from the same compromised site and you are back where you started. If a package manager is available (apt, dnf, winget, Homebrew), that is the best option — key distribution and verification are built into the mechanism, leaving you no procedure to get wrong.
MD5 and SHA-1 can no longer detect tampering	An MD5 collision takes a laptop a few seconds to produce — meaning someone can deliberately generate a harmless-looking document and a malicious executable that share an MD5. SHA-1 had a real collision published in 2017, and by 2020 a method for colliding on arbitrary chosen prefixes had been demonstrated. What that means is that the inference "the MD5 matched, therefore it is the same file" no longer holds. The algorithms remain useful for some purposes, though — for detecting accidental corruption such as a transfer error or a bad disk, MD5 still does the job perfectly well. Think of it as usable only where there is no adversary.	For security purposes, use SHA-256. This page computes all three at once, so even when only an MD5 is published, noting the SHA-256 gives you a strong comparison from then on. If you are the one distributing, publish a SHA-256 — generate it with `sha256sum file` on Linux, `shasum -a 256 file` on macOS, or `certutil -hashfile file SHA256` on Windows. The priority when fixing an existing system that uses MD5 is clear: replace it first where it backs signature verification or authentication; where it merely serves as a duplicate-detection key or a cache key, there is no urgency — because there is no path for an adversary to enter. If you are storing passwords with MD5 or even SHA-256, that is a different problem entirely — move to bcrypt or Argon2.
A mismatch is almost never tampering	When the values disagree, the first thing to suspect is a mistake in procedure. In descending order of frequency: the download was truncated (comparing the file size makes this obvious at a glance), you hashed the wrong artifact (the page lists the value for the `.iso` while you computed the `.zip`), the expected value was pasted with stray whitespace or a newline, and a difference in letter case (which is ignored here, so it is not actually a problem). The one that is easy to miss is a text file obtained through Git — on Windows with `core.autocrlf` enabled, checkout converts line endings to CRLF, which changes the bytes and therefore the hash. You get a legitimate state where the content is "the same" but the hash is not.	Compare the file size first. Distribution pages normally state the byte count — if the size differs you do not need the hash at all: it is either a different file or an incomplete download. Re-download with `curl -L -O` or `wget -c` rather than the browser; truncation is less likely and more visible. When verifying text files, align the line endings before comparing (see the line-ending converter). And the most important principle: do not run a file whose hash did not match until you know why. Deciding that it was "probably just a bad download" and running it anyway is identical to not having verified at all — downloading again and checking again costs you nothing.

Do not use hashing to anonymize personal data. Values from an effectively finite space, such as an email address or a phone number, can be reversed by brute force — there are only around a billion possible mobile numbers in a single country, so hashing all of them to build a lookup table takes minutes. Hashed personal data is still personal data in many jurisdictions. If you genuinely need this, use an HMAC with a secret key rather than a salt, or accept reversible encryption and manage the key properly. One further practical caution: the definition of "the same file" varies by format — a ZIP stores timestamps, so recompressing identical content produces a different hash. The same goes for Docker images and tar archives, and getting a different hash from every build is normal. If you need reproducible hashes, you need a reproducible-build setup that pins the timestamps.

📖 How to Use

1

Drag & drop a file

Drop the file you want to verify. Up to ~2 GB.
2

Hash is auto-computed

MD5 / SHA-1 / SHA-256 are computed in parallel, streaming for large files.
3

Compare with expected hash

Paste the expected hash from the vendor site and see match/mismatch highlighted.

❓ Frequently Asked Questions

Does it support SHA-3 / BLAKE2?

Currently supports browser-native Web Crypto (MD5, SHA-1, SHA-256/384/512). SHA-3 and BLAKE2 need extra JS libraries — planned.

Is my file uploaded to the server?

No. Files are read via FileReader and hashed with Web Crypto in your browser — no upload happens. Safe for confidential files.

How do I verify a downloaded file is untampered?

Compare our computed hash against the expected value from the vendor (usually in a .sha256 file or README). If they match, the file is untampered.

Is MD5 still safe to use?

MD5 has known collision attacks — not for security. Fine for download integrity but prefer SHA-256+ for new designs.

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.