Read the signing certificate from an APK
Upload an .apk and this page reports its signing certificate's SHA-1, SHA-256 and MD5 fingerprints in the colon-separated uppercase hex that Firebase, Google Cloud Console, the Maps SDK and assetlinks.json expect — plus the subject and issuer, the validity window, the key algorithm and size, and which signature schemes the file carries. No Android SDK, no JDK, no install.
It reads the certificate; it does not check the signature. Those are separate operations, and only the first is done here — see what this reads and what it does not below.
The Play App Signing catch, before you paste anything
The certificate inside your APK is your upload key
If the app uses Play App Signing, Google re-signs it with a different key before distributing it. The fingerprint this tool shows is therefore correct for the file you gave it and still wrong for what installed users are running. Firebase, Google Sign-In, Maps and App Links all match against the key on the device.
Two keys, two fingerprints, and nothing in the APK itself says which situation you are in. The rule is short: a build you produced carries the upload key; the app signing key exists only in Play Console.
| Key | Inside your APK? | Where to find its fingerprint |
|---|---|---|
| Upload key | Yes | This page, or your keystore |
| App signing key (Play App Signing on) | No | Play Console → Test and release → Setup → App signing |
| Release key (Play App Signing off) | Yes | This page — upload and signing key are the same |
| Debug key | Yes, in debug builds | This page, or ~/.android/debug.keystore — different on every machine |
In most projects you register more than one. A Firebase Android app should carry the app signing key fingerprint so installed users work, the upload key fingerprint so internal-testing builds work, and each developer's debug fingerprint so local runs work. Registering only one is the usual reason Google Sign-In fails on exactly one of those three.
Which fingerprint each service wants
The digests are all taken over the same bytes — the DER encoding of the whole certificate — so they are three views of one identity. What differs is which one each console matches on, and in what format.
| Where it goes | Digest | Format |
|---|---|---|
| Google Sign-In, Maps SDK for Android | SHA-1 | Colon-separated uppercase hex |
| Firebase Android app | SHA-1 and SHA-256 | Colon-separated uppercase hex |
App Links (assetlinks.json) | SHA-256 | Colon-separated uppercase hex, in sha256_cert_fingerprints |
| Google Cloud Console API key restriction | SHA-1 | Colon-separated uppercase hex |
| Facebook Android SDK key hash | SHA-1 | Base64 of the raw digest, not hex |
What this reads, and what it does not
An APK can carry four signature schemes at once, stored in two entirely different places. v1 is an ordinary zip entry. v2 and later live in the APK Signing Block, a region inserted between the last file entry and the zip central directory that nothing in the zip structure points at — reaching it means walking backwards from the end-of-central-directory record. This tool does that walk, so v2, v3 and v3.1 certificates are read, not guessed at.
| Scheme | Where the certificate lives | Read here |
|---|---|---|
| v1 (JAR signing) | META-INF/*.RSA, .DSA or .EC — a PKCS#7 blob | Yes |
| v2 (Android 7.0) | APK Signing Block, ID 0x7109871a | Yes |
| v3 (Android 9, key rotation) | APK Signing Block, ID 0xf05368c0 | Yes |
| v3.1 (Android 13) | APK Signing Block, ID 0x1b93ad61 | Yes |
| v4 (Android 11, incremental install) | Not in the APK — a separate .idsig file beside it | No |
| Signature validity (do the contents still match?) | Computed from the whole file against the signature | No — use apksigner |
The last row is the important one. Reading a certificate tells you which key an APK claims to be signed with; it says nothing about whether the file has been altered since. A modified APK still carries a perfectly readable certificate. Only a verification pass, which recomputes the content digests, can tell the two apart.
An APK signed after a v3 key rotation carries more than one certificate. Where that happens, every certificate found is listed with the schemes it appears under, and a key that signed under v1, v2 and v3 is shown once rather than three times.
The command-line equivalents
Nothing here replaces the SDK tools. It replaces the setup they need when all you have is an APK, a browser and a console asking for a fingerprint.
| What you want | Command | Needs |
|---|---|---|
| Fingerprints, plus which schemes verified | apksigner verify -v --print-certs app.apk | Android SDK build-tools |
| Fingerprints from the v1 certificate only | keytool -printcert -jarfile app.apk | A JDK |
| Fingerprints straight from your keystore | keytool -list -v -keystore my.keystore | A JDK, and the keystore password |
| The Facebook key hash | keytool -exportcert … | openssl sha1 -binary | openssl base64 | A JDK and OpenSSL |
Note what is missing from that list: nothing needs your private key. A fingerprint is computed from the certificate, which is public and already inside every APK you ship. Any tool that asks you to upload a .jks, .p12 or .keystore to read one is asking for far more than the job requires — this page refuses those file types outright.
Once the certificate checks out
Checking a fingerprint usually happens just before a build goes to someone. BetaDrop turns an .apk into an install link and QR code that a tester opens on their Android device — no Play Store listing, no review queue, no tester account. For everything else inside the file, the APK inspector reads the manifest, permissions and components in the browser. On the iOS side, the provisioning profile decoder and the IPA inspector answer the equivalent questions, and what signing an IPA actually requires covers why no site should offer to sign for you.
Frequently asked questions
How do I get the SHA-1 fingerprint of an APK?
Upload the .apk here and the SHA-1 fingerprint of its signing certificate is shown in the colon-separated uppercase format Google's consoles expect, alongside SHA-256 and MD5. On the command line the same value comes from apksigner verify --print-certs app.apk, or keytool -printcert -jarfile app.apk, both from the Android SDK build-tools and the JDK respectively. All of them hash the same thing: the DER encoding of the whole certificate.
Which fingerprint does Firebase need — SHA-1 or SHA-256?
Both, in practice. Google Sign-In and the Maps SDK for Android match on SHA-1, while Android App Links and the assetlinks.json file use SHA-256. Adding both to your Firebase Android app costs nothing and removes a whole class of "works on my machine" failures, because a build variant registered under only one of them fails the other silently.
Why does the fingerprint from my APK not work in Firebase?
Almost always Play App Signing. When it is enabled, the key you sign with is the upload key, and Google re-signs the app with a different app signing key before distributing it. A build straight from Android Studio carries the upload key, so its fingerprint is correct but is not the one installed users run under. Take the app signing key fingerprint from Play Console under Test and release, Setup, App signing, and register that one — plus the upload key, if you also test builds installed directly.
What is the difference between an upload key and an app signing key?
The upload key is what you sign a build with before sending it to Google Play; Play uses it only to confirm the upload came from you. The app signing key is what Google signs the distributed app with, and it is the identity Android checks on the device. They are different keys, with different fingerprints, and the one inside any APK you built yourself is the upload key. If Play App Signing is off, the two are the same key and the distinction does not arise.
Does this check that the APK's signature is valid?
No, and the difference matters. This reads the certificate that is stored in the APK and reports what is in it. It does not recompute the content digests or check them against the signature, so it cannot tell you whether the file has been modified since it was signed. For that, run apksigner verify -v --print-certs app.apk, which does both jobs and prints which schemes actually verified.
Which APK signature schemes can this read?
v1 (JAR signing), v2, v3 and v3.1. The v1 certificate is an ordinary zip entry under META-INF/, while v2 and later live in the APK Signing Block, an unindexed region between the last file entry and the zip central directory — this tool walks to it from the end-of-central-directory record rather than through the zip index. v4 is not readable from the APK at all: it is stored in a separate .idsig file that accompanies it for incremental installs.
Can I upload a keystore, a .p12 or a .jks file instead?
No, and the tool refuses those file types by name. Reading a fingerprint only ever needs the certificate, which is public and already inside every APK you build. A keystore also contains the private key, and anyone holding that key can sign software as you. Run keytool -list -v -keystore my.keystore locally if you need the fingerprint straight from the keystore.
Why do my debug and release builds have different fingerprints?
Because they are signed with different keys. Debug builds use the automatically generated debug keystore in ~/.android/debug.keystore, which is per-machine, so every developer on a team has a different debug fingerprint. Release builds use your own key. Any service that matches on a certificate fingerprint — Firebase, Google Sign-In, Maps, App Links — needs an entry for each signing key you actually use, including each teammate's debug key.
What happens to the APK I upload?
It is read in memory and discarded when the request finishes. Nothing is written to disk or to object storage, no build record is created, and the file is not scanned for anything beyond its signing certificates. The limit is 500 MB per file.
How do I get the SHA-256 fingerprint for assetlinks.json?
Use the SHA-256 value this page reports, with the colons kept — the sha256_cert_fingerprints field in assetlinks.json expects exactly that colon-separated uppercase hex form. If the app is distributed through Google Play with Play App Signing enabled, use the app signing key fingerprint from Play Console instead, because that is the key the installed app carries and the one Android will compare against.
