How to verify an APK's SHA-256 before you install it

Every build listed on APKBrowse publishes the SHA-256 of the exact file we hold. It is sixty-four characters long, it looks like noise, and it is the single most useful thing on the page. Most people scroll past it. This is what it is for, and how to use it before you install anything.

What a hash actually is

A SHA-256 hash is a fingerprint computed from a file's bytes. The same file always produces the same fingerprint. Change one bit — a pixel in an icon, one instruction in the compiled code — and roughly half of the output changes. You cannot work backwards from a fingerprint to a file, and nobody has ever demonstrated two different files that produce the same SHA-256. So if the hash you compute matches the hash that was published, you are holding the same file the publisher described. Not a similar file. The same one, byte for byte.

Compute it

You do not need a special tool. Every desktop operating system already ships with one, and your phone has one too if you have adb set up:

macOS / Linux   shasum -a 256 app.apk
Linux           sha256sum app.apk
Windows         certutil -hashfile app.apk SHA256
PowerShell      Get-FileHash app.apk -Algorithm SHA256
Android (adb)   adb shell sha256sum /sdcard/Download/app.apk

It prints the hash and the filename, it takes a second or two even on a large APK, and it works on the file wherever it currently sits. You do not have to move it to your phone first — and you should not install it before you check.

Compare it properly

Do not eyeball the first four characters and the last four. That is precisely the check an attacker expects you to make, and matching a short prefix and suffix is cheap: it takes a few thousand attempts, not the astronomical effort a real collision would need. The middle is where the difference will be.

Let a machine do the comparison instead. On macOS or Linux you can hand the published hash straight to the same tool and have it answer with one word:

echo "PASTE_THE_PUBLISHED_HASH_HERE  app.apk" | shasum -a 256 -c

app.apk: OK

Note the two spaces between the hash and the filename — the format is fussy about it. If you get OK, the file is the one that was published. If you get FAILED, it is not, and no amount of squinting at the two strings will change that.

What a match proves, and what it does not

A matching hash proves integrity, not safety. It tells you the file was not altered between the publisher and you: no truncated download, no injected payload, no substitution by whoever happens to run the network you are on. It tells you nothing about whether the app is any good, whether it respects your privacy, or whether the developer deserves your trust. A thoroughly malicious app has a perfectly valid hash. Integrity and trustworthiness are different questions and the hash only answers the first one.

Where the hash came from matters more than the hash

A fingerprint is only as good as the channel you got it from. If an attacker controls both the file and the page listing its hash, they will simply publish the hash of their own file, and your check will pass beautifully. This is the part that gets skipped: verification is only meaningful when the hash and the file come from places that would have to be compromised separately.

So prefer a hash you can obtain from the developer directly — a release page, a signed git tag, a project mailing list — and compare that against the file you downloaded from wherever you downloaded it. APKBrowse records the SHA-256 for every build we hold, and you are welcome to use ours. But if you can get the same number from the people who compiled the code, that is the stronger check, and we would rather you made it.

When they do not match

Stop. Delete the file. Do not install it just to see what happens.

A mismatch has boring explanations and alarming ones. The boring ones: the download was truncated, a mirror is serving an older build, the listing has not caught up with a re-release. The alarming one: what you received is not what was published. You cannot tell which from the hash alone, and the cost of guessing wrong is an application with access to your notifications, your clipboard and whatever you type next.

Download the file once more, ideally from a different network. If the second copy matches, the first was probably just broken in transit. If it still does not match, report the listing and include both hashes — the one you computed and the one we published. That pair is exactly what lets a moderator tell a bad listing apart from a bad download.

One thing a hash will never do

APKBrowse does not run malware scans, and this article is a good place to say so plainly. We record the SHA-256 of every build we host and the certificate that signed it, and we put the official store link first whenever one exists. Those are provenance checks: they establish where a file came from and whether it changed on the way to you. They are not a verdict on what the code does once it is running on your phone.

Treat a verified hash as a good reason to trust the delivery. Everything after that — the permissions it asks for, the publisher behind it, and whether you needed to sideload it at all — is still a judgement you have to make yourself.