Check a File's SHA-256 Checksum on Android
A download page lists a SHA-256 hash and you want to verify the file. Here's how to check it on a phone, and what a matching hash does and doesn't prove.
To verify a download, compute its SHA-256 hash and compare it character-for-character with the one the publisher listed. A matching hash proves the file you have is byte-identical to the file whose hash was published — nothing more and nothing less. That distinction matters: if the hash came from the same page as the download, you have proved the file arrived intact, not that it is trustworthy, because anyone who could replace the file could replace the hash beside it.
On Android, Convertlix's Hash Checker computes MD5, SHA-1 and SHA-256 checksums on the handset, so the file never leaves the device — no upload, no server-side copy, nothing to retain. The scope, up front: Android 8.0 or later, sign-in required (there is no guest mode), 25 MB per file on the free tier against a server-set monthly allowance of conversions shown in the app. That cap matters here more than elsewhere, and the limits section says why.
What a hash is, in one paragraph
A cryptographic hash function reads every byte of a file and produces a fixed-length fingerprint — 64 hexadecimal characters for SHA-256, regardless of whether the input was a 12-byte text file or a 4 GB disk image. Two properties make it useful: the same input always produces the same output, and changing a single bit anywhere in the file produces a completely different, unpredictable output. There is no partial match. A one-byte truncation and a malicious rewrite look equally different.
That is why the comparison is binary. You are not looking for "close"; you are looking for identical.
MD5, SHA-1, SHA-256: which to use and which not to trust
All three are still in circulation, and they are not interchangeable.
| Algorithm | Length | Status | Use it for |
|---|---|---|---|
| MD5 | 32 hex chars | Collision-broken since 2004 | Detecting accidental corruption, deduplicating your own files |
| SHA-1 | 40 hex chars | Collision-broken (SHAttered, 2017) | Legacy compatibility only |
| SHA-256 | 64 hex chars | Currently considered secure | Verifying downloads, anything security-relevant |
"Collision-broken" has a precise meaning worth getting right, because it is widely misstated. A collision attack means someone can construct two different files with the same hash. It does not mean they can take your file's MD5 and build a malicious file matching it — that is a second-preimage attack, and MD5 has not fallen to a practical one.
So the honest reading: MD5 is still perfectly good at catching a corrupted download, which is what most people are actually doing, and it is faster. It is not good enough when an adversary might have crafted the file, because they could have prepared both versions in advance. Since SHA-256 is fast enough on any modern phone that the difference doesn't matter, use SHA-256 when the answer matters and don't lose sleep about MD5 for a checksum on your own backup.
The part most guides skip: where the hash came from
This is the section that makes the whole exercise worth doing properly.
A hash verifies integrity — the file is unaltered since the hash was computed. On its own it does not verify authenticity — that the publisher is who you think and intended to publish this file. Those need different evidence.
If the checksum is printed on the same web page as the download link, then:
- ✅ You have caught a truncated or corrupted transfer, a bad mirror, and a proxy that mangled the file. That is genuinely common and genuinely worth catching.
- ❌ You have not caught a compromised download server or a tampered page, because whoever changed the file changed the hash on the way past.
To get authenticity you need the hash — or better, a signature — from a channel the attacker doesn't control:
- A GPG or PGP signature over the file or over the checksum file, verified against
a key you obtained separately. This is the strong version, and it is why Linux
distributions publish
SHA256SUMSandSHA256SUMS.gpg. - The hash published somewhere independent: the project's source repository, its release notes on a different host, a package manager's manifest, or a well-known mirror.
- HTTPS on the download itself, which authenticates the server — useful, and not the same as authenticating the file, since a compromised server serves malicious files over a perfectly valid certificate.
None of that makes checking a same-page hash pointless. It makes it a corruption check, which is what to call it.
How to verify a download's checksum on a phone
- Find the published hash and note which algorithm it is. Count the characters if the page doesn't say: 32 is MD5, 40 is SHA-1, 64 is SHA-256. Copy it somewhere you can see it next to the result.
- Ask where that hash came from. Same page as the file, or an independent source or signature? This decides whether you are checking for corruption or for tampering, and it is the difference between a routine check and a meaningful one.
- Compute the same algorithm over the file you downloaded. In Convertlix, open Hash Checker, pick the file through Android's file picker and select MD5, SHA-1 or SHA-256. Comparing a SHA-256 against a published MD5 tells you nothing.
- Compare the whole string, not the ends. Paste both into a text field and look, or compare in chunks. Eyeballing the first and last six characters is the standard way people convince themselves a mismatched file matched.
- If it doesn't match, re-download before you conclude anything. Interrupted transfers are far more common than tampering. A second download that produces the same wrong hash is the point at which to be suspicious of the source.
When this doesn't work
- Large files on the free tier. The free per-file cap is 25 MB, and the files people most want to verify — OS images, installers, big archives — are usually much larger than that. That is a genuine limitation of doing this on the free tier; Premium raises the ceiling to 2 GB, and a desktop command is free and unlimited.
- You are verifying against a hash from the same compromised source. Covered above: the check succeeds and proves nothing about authenticity.
- The publisher lists no hash at all. There is nothing to compare against. A hash you compute yourself is only useful later, as a record that the file hasn't changed since you got it.
- The file is expected to differ. Some downloads are built per request, watermarked per user, or served through a CDN that recompresses. A mismatch there is not a problem, and the publisher won't be listing a hash for it.
- You need to verify signatures rather than hashes. GPG verification is a different operation with different tools, and it is the stronger check. A phone hash tool doesn't do it.
- Checking that a file is safe. A hash says nothing about content. A verified, authentic file can still be malware if the publisher intended it to be. Verification and trust are separate questions.
FAQ
What does it mean if the checksum doesn't match?
It means the file you have is not byte-identical to the one whose hash was published. Overwhelmingly the cause is an incomplete or corrupted download — an interrupted transfer, a bad mirror, or a proxy that altered the file — so re-downloading is the first thing to try. If a fresh download produces the same mismatch, stop using the file and treat the source as suspect.
Is MD5 good enough for checking a download?
For catching accidental corruption, yes — MD5 reliably detects a truncated or damaged file and is fast. It is not good enough when someone might have deliberately crafted the file, because practical collision attacks let an attacker prepare two different files with the same MD5 in advance. Since SHA-256 costs nothing noticeable on a modern phone, use it whenever the answer matters.
Does a matching hash mean the file is safe?
No. A matching hash means the file is unaltered relative to the published hash. It says nothing about what the file does, and if the hash came from the same page as the download, it does not even prove the publisher intended to publish that file — anyone who could replace the file could replace the hash next to it. Authenticity needs a signature, or a hash from an independent channel.
Does Convertlix upload my file to compute the hash?
No. The file is opened through Android's own file picker and hashed on the phone, byte by byte, and nothing is sent anywhere — the app has no storage permission, so it cannot read anything you did not hand it. Its network calls carry identity, licence, quota, configuration and payment data, never a file. Sign in once, switch on airplane mode, and it still computes. That is worth caring about here specifically: a browser-based hash tool that uploads the file has copied whatever you were verifying.
Is there a free way to check a checksum without an app?
Yes, and on a computer it is built in. Linux and macOS have sha256sum and
shasum -a 256; Windows PowerShell has Get-FileHash -Algorithm SHA256 file.iso; all
free, unlimited in file size and already installed. On Android, some file managers and
terminal apps like Termux expose the same commands. Those are the better option for a
4 GB ISO, and the reason to use a phone tool is that the file is on the phone and you
want to check it without moving it anywhere.
If the file is on your phone and a page has given you a hash to check it against, compute the same algorithm on the device and compare the whole string, not the ends.