How to check APK file integrity before installing
Integrity verification confirms that the file you downloaded is byte-for-byte identical to what the developer published. It catches corruption, incomplete downloads, and tampering—but it does not, on its own, prove the app is safe to use.
What file integrity means in plain language
Every digital file is a sequence of bytes. If even one byte changes—whether by network error, disk fault, or deliberate modification—the file is no longer identical to the original. Integrity checking answers one question: is this file exactly what the publisher intended to distribute?
When you download an APK from a developer's website, you are trusting that the file arrived without alteration. Most of the time it does. But downloads can be truncated by unstable connections, cached incorrectly by a CDN, or replaced by a compromised mirror. Integrity verification gives you a way to detect these problems before you install.
How checksums work (SHA-256)
A checksum is a fixed-length string generated by running a file through a mathematical function called a hash algorithm. The most widely used algorithm for this purpose is SHA-256, which produces a 64-character hexadecimal string regardless of file size.
Two key properties make this useful:
- Deterministic: The same file always produces the same hash. If you and the developer both run SHA-256 on the same APK, the output will match exactly.
- Sensitive to change: Altering even one byte in the file produces a completely different hash. There is no way to predict what the new hash will be, and no way to modify a file while preserving its original hash (within practical computation limits).
When a developer publishes a SHA-256 hash alongside a download link, they are providing a reference value. You download the file, compute the hash on your end, and compare the two strings. If they match, the file is intact. If they do not, something changed the file after the developer published it.
When you should compare hashes
Hash comparison is most valuable in these situations:
- The developer publishes a hash. Open-source projects on GitHub, F-Droid listings, and security-focused developers often include SHA-256 values on their release pages. This is the ideal case—you have a reference value from a trusted source.
- You downloaded from a mirror or third-party archive. If you did not download directly from the developer, comparing against their published hash confirms the mirror did not modify the file.
- The download was interrupted or slow. A file that transferred over an unstable mobile connection may be truncated. Hash comparison catches this immediately.
- You transferred the file between devices. Copying an APK via Bluetooth, USB, or a messaging app can occasionally corrupt the file. Verify after transfer.
When you realistically cannot compare hashes
Many developers—especially smaller teams and commercial app publishers—do not publish checksums at all. In these cases, you cannot perform a hash comparison because there is no reference value to compare against. This is common and does not automatically mean the download is untrustworthy. It simply means you need to rely on other signals:
- Did you download from the developer's own website over HTTPS?
- Does the file size match what the download page listed?
- Does the package name in the installer match the app you expect?
- Does Google Play Protect flag the file when you attempt to install?
These are weaker checks than a cryptographic hash, but they still catch many common problems. When no hash is available, they are the practical alternative.
Step-by-step: computing and comparing a SHA-256 hash
On Windows (PowerShell)
- Open PowerShell (search "PowerShell" in the Start menu).
- Run:
Get-FileHash -Algorithm SHA256 "C:\Users\You\Downloads\app.apk" - The output includes a
Hashfield—a 64-character hexadecimal string. - Compare it to the developer's published value. The comparison is case-insensitive.
On macOS (Terminal)
- Open Terminal.
- Run:
shasum -a 256 ~/Downloads/app.apk - The hash is the first value in the output line. Compare it to the reference.
On Linux (Terminal)
- Open a terminal.
- Run:
sha256sum ~/Downloads/app.apk - Compare the output hash to the developer's published value.
On Android (without a computer)
File-manager apps such as Solid Explorer and MiXplorer can compute checksums directly on the device. Long-press the APK file, open its properties or details panel, and look for a checksum or hash option. This is less convenient than a desktop terminal but works when you do not have access to a computer.
Warning signs of a tampered or corrupt APK
Even without a published hash, several observable signals suggest a file may have been altered or is not what it claims to be:
- File size mismatch: If the developer's download page lists a file size (e.g., "24.3 MB") and your downloaded file is significantly smaller or larger, the file may be truncated, padded, or replaced entirely.
- Unexpected package name at install: When the Android installer displays the app name and package ID, compare them to what you expected. A file named
whatsapp.apkthat installs ascom.example.freecoinsis not what it claims to be. - Excessive or unusual permissions: A calculator app requesting access to your contacts, camera, and SMS is a red flag. Review the permission list shown by the installer before proceeding. Some repackaged APKs inject additional permissions not present in the original.
- Inconsistent source: If the developer's website links to Google Play but you found the APK on an unrelated file-sharing site, the file may have been modified by the uploader. Prefer the source the developer actually endorses.
- Missing or broken APK signature: Android requires all APKs to be signed. If the installer reports a signature verification failure, the file has been modified after signing. Do not install it.
What integrity checks cannot tell you
A matching hash proves the file was not altered after the developer published it. It does not prove:
- That the app is free of malware. If the developer's own build contains malicious code, the hash will still match. Integrity verification confirms fidelity to the source, not the trustworthiness of the source itself.
- That the developer's infrastructure was not compromised. If an attacker replaces both the APK and the published hash on the developer's website, the values will match even though the file is not the original. This is rare but not impossible.
- That the app is compatible with your device. A valid, intact APK can still crash on launch if it targets a different Android version or CPU architecture. Integrity and compatibility are separate concerns.
Integrity checking is one layer in a broader verification process. Combine it with source verification, permission review, and Play Protect scanning. For a full sideloading checklist, see How to install APK files safely.
Edge cases and common mistakes
- Comparing hashes from different versions: If the developer updated the APK since you copied the hash, the values will not match even though both files are legitimate. Always copy the hash from the same release page as the download link you used.
- Using MD5 instead of SHA-256: Some older guides and download pages still list MD5 hashes. MD5 is considered cryptographically broken—it is possible to create two different files with the same MD5 hash. If only MD5 is available, it still catches accidental corruption, but it does not protect against deliberate tampering. Prefer SHA-256 whenever the developer offers it.
- Copying the hash incorrectly: Hash strings are long and easy to mis-copy. Always copy and paste rather than typing by hand. When pasting into a comparison, check for trailing spaces or line breaks that some websites insert.
- Assuming the APK is safe because the hash matches: As noted above, a matching hash only confirms the file was not altered in transit. It says nothing about what the app does once installed. Do not skip permission review or source verification just because the hash checks out.
- Verifying a split-APK bundle as a single file: If the developer distributes a ZIP or XAPK containing multiple split APKs, the published hash applies to the bundle file—not to the individual APKs inside. Hash the outer file before extracting.
- Re-downloading to the same filename: Some browsers append a number to duplicate filenames (e.g.,
app (1).apk). Make sure you are hashing the file you actually intend to install, not an earlier partial download with a similar name.
Note: If a developer does not publish checksums and you are concerned about file integrity, consider requesting it. Many developers are willing to add SHA-256 values to their release pages once they understand the use case. In the meantime, downloading directly from the developer's HTTPS site and reviewing the installer's signature check remain your best practical defences.
Frequently asked questions
Is MD5 still acceptable for verifying APKs?
MD5 detects accidental corruption (download errors, incomplete transfers) but is cryptographically broken—two different files can be engineered to produce the same MD5 hash. It does not protect against deliberate tampering. Use SHA-256 or SHA-512 when the developer provides either. If only MD5 is available, treat it as a corruption check, not a security guarantee.
Can I verify an APK entirely on my phone without a computer?
Yes. File managers such as Solid Explorer and MiXplorer can compute SHA-256 hashes on-device. The process is slower than on a desktop and the interface varies by app, but the result is identical. You can also use a terminal emulator like Termux and run sha256sum directly.
Does APK signing replace the need for hash verification?
They serve different purposes. APK signing confirms the developer's identity—the same key that signed the Play Store version should sign the sideloaded version. Hash verification confirms the file was not altered after the developer published it. Signing does not detect a truncated download; hashing does not confirm who built the file. Both checks are useful, and neither replaces the other.
The hash matches but the app still crashes — what went wrong?
A matching hash means the file is intact. Crashes after a successful integrity check are caused by compatibility issues (wrong Android version, wrong CPU architecture), insufficient storage for runtime extraction, or conflicts with existing app data. See How to fix app crash after install for diagnostic steps.
Where do I find the developer's published hash?
Look on the same page as the download link. GitHub release pages, F-Droid build listings, and security-conscious developers typically display SHA-256 values next to each file. Some developers publish hashes in a separate .sha256 text file alongside the APK. If no hash is published anywhere on the developer's site, you cannot perform this check—rely on HTTPS, file-size comparison, and installer-level signature verification instead.