What assetlinks.json Does
assetlinks.json is Android's half of the trust check behind App Links. Your app's manifest says "I handle links on example.com." The file on example.com says "the app with this package name and this signing certificate may handle my links." When both statements match, Android marks the domain as verified and opens your app directly when a user taps a link.
The file comes from Google's Digital Asset Links protocol, which is a general way for websites and apps to make public statements about each other. App Links use one specific statement, delegate_permission/common.handle_all_urls, but the same file can also share sign-in credentials between a website and an app.
Without a verified file, an Android link either shows a disambiguation dialog asking which app should open it or, on Android 12 and later, opens in the browser. Verification is what turns a regular HTTPS link into an App Link.
File Format
The file is a JSON array of statements. Each statement has a relation array, usually containing delegate_permission/common.handle_all_urls, and a target object. For an Android app, the target has namespace: "android_app", the app's package_name, and a sha256_cert_fingerprints array.
The fingerprint is the part teams get wrong most often. It must be the SHA-256 fingerprint of the certificate that signs the build on the user's device, written as colon-separated uppercase hex. Apps enrolled in Play App Signing are re-signed by Google, so the correct value is the app signing key certificate in Play Console under app integrity, not the upload key on your build machine. List several fingerprints if you ship debug, staging or sideloaded builds with different keys.
One file can authorise several apps. Add one statement per package name, which is useful for a main app and a lite app, or separate consumer and partner apps on one domain.
Hosting and Verification
Host the file at /.well-known/assetlinks.json on every host that appears in your manifest's intent filters. A filter covering example.com and www.example.com needs the file on both. Serve it over HTTPS with a valid certificate, return Content-Type: application/json, and do not redirect. The verifier does not follow redirects for this file.
In the app, each intent filter that should verify needs android:autoVerify="true", the VIEW action, the DEFAULT and BROWSABLE categories, and https data elements for the hosts. When the app is installed or updated, Android contacts the domains and records whether verification passed. On Android 12 and later, verification runs per domain, so one bad host does not block the others, but it also means each host needs its own working file.
If a domain fails verification, users can still enable it manually in the app's "Open by default" settings, but almost no one does. Treat a failed verification as broken links.
Testing and Debugging
Start with the file itself. Load the URL in a browser, check for a 200 response without redirects, and validate the JSON. Then confirm the package name and fingerprint against Play Console.
On a device, adb shell pm get-app-links com.example.app lists each domain and its state, such as verified or none. After fixing the file, adb shell pm verify-app-links --re-verify com.example.app asks Android to check again. Google also offers a Statement List Generator and Tester, and a public Digital Asset Links API endpoint that returns whether a given site and app are linked.
Test links by tapping them from another app, such as a chat or notes app. Typing a URL into Chrome's address bar keeps the user on the web by design.
Managing assetlinks.json at Scale
Every new link domain, subdomain or app variant means another file to keep correct. Teams that run campaign links on a branded subdomain, such as go.example.com, need the file there too, and a signing key rotation means updating every host.
Deep linking providers that run links on your domain usually host this file for you. Linkrunner hosts both assetlinks.json and the iOS apple-app-site-association file for your link domain, so Android and iOS verification stay in sync with your app settings. See deep linking for branded domains and App Links setup, and check the iOS side with the AASA validator.