Free Tool

4.9/5

Free Android App Links Validator

Fetch and validate your assetlinks.json file for Android App Links. Catch missing relations, bad package names, and malformed SHA-256 fingerprints before they break auto-verification.

Domain to validate *

Fetches https://<domain>/.well-known/assetlinks.json and validates Digital Asset Links for Android App Links.

Shorten the links that open your app

Create Flyn short links that route to your App Links, counting every click free with device, country, and referrer breakdowns on Pro. Every install link becomes a data point you control.

Shorten for free

How to Validate Your assetlinks.json in 3 Steps

Enter your domain

Paste the domain that hosts your app. The validator fetches the assetlinks.json file from the .well-known path over HTTPS, exactly the way Android does.

Review every check

Get pass, warning, and fail results for reachability, the JSON array, the handle_all_urls relation, the android_app namespace, package name, and fingerprint format.

Fix and re-validate

Each failed check ships with a concrete fix: add the missing relation, correct the package name, or include the Play App Signing fingerprint. Apply it and re-run.

What Is the assetlinks.json File?

assetlinks.json is a Digital Asset Links file you host on your own domain. It is the contract between your website and your Android app: it declares which app, signed with which certificate, is allowed to handle links to your domain. This is the foundation of Android App Links, the mechanism that lets a tap on one of your URLs open your app directly instead of the browser or a disambiguation dialog.

When your app declares an intent filter with android:autoVerify set to true, Android fetches your assetlinks.json at install time, confirms that a statement grants the handle_all_urls permission to your package with a matching signing fingerprint, and marks your App Links as verified. If the file is missing, not an array, lacks the required relation, or lists the wrong fingerprint, verification fails silently and your links stop opening the app. Validating the public file directly is the fastest way to catch this.

What This Validator Checks

Every requirement Android cares about, with a clear pass, warning, or fail and a fix for each.

Reachable over HTTPS

The file must respond with HTTP 200 over HTTPS at the .well-known path. Android follows redirects to reach it, but serving it directly with a 200 is the most reliable setup.

Content-Type application/json

Android expects the file to be served as application/json. The validator warns if the Content-Type is missing or wrong so you can fix the server configuration.

Top level is a JSON array

assetlinks.json must be a JSON array of statement objects, even for a single app. A bare object instead of an array is the most common structural mistake.

handle_all_urls relation

At least one android_app statement must include the exact relation delegate_permission/common.handle_all_urls. Without it, Android will not auto-verify your App Links.

android_app namespace

Each App Links statement must target an android_app. Statements with a web or other namespace are flagged because they do not enable App Links.

Valid package_name

The package_name must be present and a valid reverse-DNS application ID, like com.example.app, matching your app build configuration exactly.

SHA-256 fingerprint format

sha256_cert_fingerprints must be a non-empty array of 32-byte uppercase hex fingerprints separated by colons. Each malformed fingerprint is called out individually.

Overall App Links readiness

The validator confirms that, across all statements, at least one android_app grants handle_all_urls, so you know the file as a whole meets the auto-verification requirement.

Where the assetlinks.json File Must Live

Android fetches the file from https://yourdomain.com/.well-known/assetlinks.json. The path is fixed: it must be under /.well-known/ and named assetlinks.json exactly. The file must be served over HTTPS, return HTTP 200, be delivered as application/json, and contain a valid JSON array. Android does follow redirects to reach the file, but serving it directly is the most predictable setup.

If you serve App Links from multiple domains or subdomains, each one needs its own assetlinks.json with a statement for your app. Remember that auto-verification also depends on your manifest: the intent filter must set android:autoVerify to true and declare a BROWSABLE, DEFAULT, https filter for the host. Validate the public file here, then confirm the manifest and signing fingerprints in your build.

Common assetlinks.json Errors and How to Fix Them

The mistakes that silently break App Links most often.

Wrapping a single statement as an object

The file must be an array even for one app. Starting with { instead of [ makes Android reject it. Wrap your statement in square brackets.

Missing the handle_all_urls relation

Auto-verification needs the exact relation delegate_permission/common.handle_all_urls in an android_app statement. A typo or omission means links never auto-open your app.

Forgetting the Play App Signing fingerprint

With Play App Signing, the production cert is Google managed. List the SHA-256 from the Play Console App integrity page, not just your local upload or debug key.

Wrong package_name

The package_name must match your applicationId exactly. A mismatch grants permission to a nonexistent app and verification quietly fails.

Malformed fingerprints

Lowercase hex, missing colons, or a truncated value all break verification. Each fingerprint must be 32 uppercase hex bytes separated by colons (95 characters).

Manifest missing autoVerify

Even a perfect file does nothing without android:autoVerify="true" and a BROWSABLE, https intent filter in your manifest. Validate the file here, then check the manifest.

Verified App Links + Trackable Short Links

Validate your assetlinks.json here, then use Flyn to wrap your App Links in short links that count every tap, with device, country, and referrer breakdowns on Pro.

Deep link routing

Send users straight into your app with short links that respect your App Links setup.

Click analytics

Every tap is counted as it happens, and Pro logs device, OS, country, and referrer detail. Know which channels drive installs.

Branded domains

Custom domains with automatic HTTPS on Pro. Branded short links build trust before the tap.

Instant redirects

Global edge delivery means redirects feel instant, so your install funnel never loses momentum.

Frequently Asked Questions

What is the assetlinks.json file?

assetlinks.json is a Digital Asset Links file you host on your domain that tells Android which app is allowed to handle links to your site. It is the Android equivalent of the iOS apple-app-site-association file. When it is present and correct, Android can auto-verify your App Links so that taps on your URLs open your app directly instead of showing a chooser dialog or opening the browser.

Where exactly does assetlinks.json need to live?

Android fetches the file from https://yourdomain.com/.well-known/assetlinks.json. It must be served over HTTPS, return HTTP 200, and be delivered with the Content-Type application/json. The path is fixed: it must be under /.well-known/ and named assetlinks.json exactly. Unlike iOS, Android does follow redirects to reach the file, but serving it directly with a 200 is still the most reliable approach.

What is the handle_all_urls relation and why does it matter?

The relation array in each statement declares what permission you are granting. For Android App Links auto-verification, at least one android_app statement must include the exact string "delegate_permission/common.handle_all_urls". This grants the app permission to handle every URL on the domain. If this relation is missing, Android will not auto-verify your links and they will not open your app automatically.

What format does the file need to be in?

assetlinks.json must be a JSON array (in square brackets), even if it contains only one statement. Each element is an object with a "relation" array and a "target" object. A common mistake is wrapping a single statement as a bare object instead of an array, which makes Android reject the file. This validator fails the file if the top level is not an array.

What is the package_name and how is it validated?

The package_name is your app application ID in reverse-DNS form, for example com.example.app. It must match the applicationId in your app build configuration exactly. This validator confirms the value is present and looks like a valid reverse-DNS identifier. A typo here means Android grants the permission to the wrong (nonexistent) app and verification fails.

What are sha256_cert_fingerprints and where do I get them?

The sha256_cert_fingerprints array lists the SHA-256 fingerprints of the signing certificates allowed to act as your app. Each fingerprint is 32 bytes shown as uppercase hex pairs separated by colons, 95 characters total. You can get yours with keytool from your keystore, or copy it from the Play Console under App integrity (Play App Signing has its own SHA-256 you must include). This validator checks that each fingerprint has the exact expected shape.

Why do I need to include the Play App Signing fingerprint?

If you use Play App Signing (the default for new apps), Google re-signs your app with its own key before distribution. That means the certificate users actually run is the Play signing key, not your upload key. You must list the SHA-256 fingerprint from the Play Console App integrity page, otherwise auto-verification fails in production even though it worked with your local debug or upload key.

My assetlinks.json looks correct but App Links still do not verify. Why?

Common causes beyond the file: the intent filter in your manifest is missing android:autoVerify="true", the BROWSABLE category or the DEFAULT category is missing, the data scheme is not https, the wrong SHA-256 fingerprint is listed (especially missing the Play App Signing key), or the verification has not retried yet. You can inspect the device verification state with adb shell pm get-app-links your.package. Validate the file here first, then check the manifest.

Can one assetlinks.json grant access to multiple apps?

Yes. The file is an array, so you can include multiple statements, each targeting a different android_app with its own package_name and fingerprints. This is how you associate several apps, or several signing keys (debug, upload, and Play App Signing), with the same domain. This validator checks every statement in the array independently.

How is this different from the iOS AASA file?

They serve the same purpose on different platforms. iOS uses apple-app-site-association (no extension, no redirects allowed, app IDs as TEAMID.bundle), while Android uses assetlinks.json (a JSON array, application/json content type, package name plus SHA-256 fingerprints). If you ship on both platforms you need both files. Use this tool for Android and the AASA Validator for iOS.

Does Android cache the verification result?

Yes. Android verifies App Links at install time and caches the result. If you fix assetlinks.json after the app is installed, the device may not re-verify until the app is reinstalled or the verification retries. On Android 12 and later you can manually trigger re-verification through adb. Always re-run this validator after any change so you know the public file is correct before testing on a device.

Is this validator free and does it store my data?

Yes, it is completely free with no sign-up. We keep a small history of domains you have checked in your browser localStorage so you can re-run them, and it never leaves your device. On the server we rate-limit by IP and do not persist the domains you check. Your server will see a request from Flyn-Bot/1.0 in its logs, the same as any other client fetching the public file.

Ready to ship reliable deep links?

Validate your assetlinks.json for free, then use Flyn to share short links that route into your app with click tracking and QR codes free, plus analytics breakdowns and custom domains on Pro, all in one platform.

Start free, no credit card Read the API Docs