Assetlinks validator — find out why your App Links won't verify on Android

paste your domain. find out why your App Links won't verify on Android.

what this tool does

Takes a domain, fetches https://{domain}/.well-known/assetlinks.json, validates the file against Google's Digital Asset Links specification, and cross-checks Google's Statement List API for the same domain to verify what Google's verifier actually sees. Reports: HTTP status, Content-Type, JSON parse status, each statement's structure (relation, target.namespace, target.package_name, target.sha256_cert_fingerprints), fingerprint format correctness, and — critically — whether Google's Statement List API confirms verification for the package/fingerprint pair. Outputs annotated pass/fail.

It also flags the platform-specific edge cases that catch every Android team at some point: the upper-case-vs-lower-case fingerprint mismatch (Google's verifier is case-sensitive in places the spec doesn't make obvious), the colon-separator format (some signing-key extraction commands omit them), the Play App Signing fingerprint vs the upload-key fingerprint divergence (if you use Play App Signing, the fingerprint your app ships with is NOT the fingerprint you have locally), and the autoVerify vs assetlinks.json chicken-and-egg problem.

why this matters

Android App Links (Google's equivalent to iOS Universal Links) require the device to verify that the app has the right to handle a given domain's URLs. The verification runs at app-install time, runs against the /.well-known/assetlinks.json file on the claimed domain, and runs entirely silently. If verification fails, the user taps your URL, Android shows a chooser ("open with...?") instead of routing directly to your app, and your one-tap deeplink experience becomes a multi-tap drop-off. Most users pick the browser. Your conversion silently halves.

Like AASA on iOS, the failure modes are stupid and the diagnostic surface is approximately zero. The fingerprint in your assetlinks.json is the upload-key fingerprint instead of the Play App Signing fingerprint. The fingerprint is correctly extracted but pasted with the wrong colon convention. The file is missing the second statement that Chrome's Web Intents requires. The file is correct on www.example.com but example.com redirects there and Google's verifier doesn't follow the redirect. The package_name has a typo. The autoVerify="true" flag in the manifest is missing so verification never runs in the first place.

Each is a one-line fix once you know which. The validator surfaces it.

For the underlying explanation — what assetlinks.json is, how Android App Link verification works, why Play App Signing changes the fingerprint — see /guides/assetlinks-json-explained and /guides/android-app-links-setup.

what you'll see

1. Domain input. Enter a domain (without https://). Validate button.
2. Fetch block. Status. Content-Type (Google requires application/json). Final URL. Redirect count (Google does not follow redirects on this file — same as Apple).
3. File contents pane. JSON with syntax highlighting and line numbers.
4. Validation pane. Each statement in the file is validated individually:
   • PASS / FAIL: top-level structure is an array
   • PASS / FAIL: each statement has relation and target
   • PASS / FAIL: relation value is one of the accepted strings
   • PASS / FAIL: target.namespace is android_app
   • PASS / FAIL: target.package_name is a valid Android package
   • PASS / FAIL: each sha256_cert_fingerprints entry matches the SHA-256 fingerprint format (AA:BB:CC:... with colons, uppercase hex, 64 hex chars)
5. Google Statement List API check. A separate block — the validator queries Google's Statement List API at https://digitalassetlinks.googleapis.com/v1/statements:list with your domain and package name, and reports what Google's verifier currently says. This is the ground-truth check. If your file is perfect locally but the API says "not verified," there's a propagation lag or a fingerprint mismatch you haven't caught.
6. Fingerprint hint. A separate input where you can paste the fingerprint your gradle signingReport or keytool returned, and the validator confirms it matches one of the fingerprints in the assetlinks.json file — catching the upload-key-vs-Play-App-Signing-key confusion before it ships.
7. Fix suggestions. Annotated next to each FAIL.
8. Copy result as report button.

who this is for

Android developers debugging an App Link that opens the chooser instead of the app directly, where the manifest looks right and the file is hosted.

DevOps and SREs setting up the assetlinks file for the first time, who need confirmation that Google's verifier sees what they think it sees.

Migration teams moving off Firebase Dynamic Links onto direct App Links + intent-URL handoff, who need to verify the replacement assetlinks file matches the previous FDL configuration.

QA engineers verifying that a Play release with a rotated signing key correctly updated the production assetlinks.json before users on the new version started hitting the chooser.

currently in development

We're building this. The validation rules and the Statement List API cross-check are codified. The work is the fingerprint-hint UX and the Play App Signing detection (we can sometimes infer from the file whether Play App Signing is in play, which catches the most common misconfiguration).

Notify me when this validator launches — built by engineers, for engineers.

Get notified →

in the meantime

If you need to validate today:

• Google's official documentation is at developer.android.com/training/app-links/verify-android-applinks{rel="nofollow"}. The "Test your App Links" section covers the manual verification commands.
• Google's Statement List API tester at developers.google.com/digital-asset-links/v1/getting-started{rel="nofollow"} returns what Google's verifier currently sees for a given domain + package. This is the ground-truth check. Paste your domain and package, see what comes back. If it's empty, you have a problem.
• adb shell pm verify-app-links --re-verify your.package.name on a connected Android device runs the verifier manually. If the result is "verified," your file is good. If "not verified" or "domains-status: legacy_failure," the verifier rejected something.
• keytool -list -v -keystore your.keystore -alias your-alias produces the SHA-256 fingerprint to paste into assetlinks.json. For Play App Signing keys, the fingerprint is in the Play Console under Setup → App Integrity.

related

Continue reading:

• assetlinks.json explained
• Android App Links setup
• Universal Links vs deep links
• Firebase Dynamic Links replacement

Sister tool:

• AASA validator — iOS equivalent

Related tools:

• Deeplink tester — once your assetlinks file verifies, test the full deeplink across environments
• User-agent checker

Developer reference:

• /api — linkboo's deeplink API
• /docs — integration documentation