assetlinks.json validator
Check your Digital Asset Links file the way Android verifies App Links. Enter a domain and we test the fetch, the headers, the JSON and each fingerprint.
Enter a domain above and press Enter or Check file. We run 9 checks and explain each one.
What this checks
- Reachable over HTTPS
- We request /.well-known/assetlinks.json on your domain.
- HTTP status 200
- Any other status means Android finds no file.
- No redirect
- Android does not follow redirects when it verifies a domain.
- Content type
- The file should be served as application/json.
- Valid JSON array
- The top level of the file is a list of statements.
- Relation
- At least one statement includes delegate_permission/common.handle_all_urls.
- Target namespace
- The target namespace is android_app.
- Package name format
- Lowercase segments separated by dots, such as com.acme.app.
- SHA-256 fingerprint format
- 32 pairs of hex digits separated by colons.
What assetlinks.json does
Android App Links only open your app directly when the system has verified that you own the domain. It does that by fetching assetlinks.json from your domain and matching your package name and signing certificate fingerprint. If anything is off, autoVerify fails quietly and links fall back to a chooser or the browser.
This validator fetches the file the way Android does, then checks the relation, the namespace, the package name and the format of every SHA-256 fingerprint. It cannot see which key signed your build, so it checks that each fingerprint is well formed, not that it is the right one.
Frequently asked questions
Serve it over HTTPS at /.well-known/assetlinks.json on every host named in your intent filters. The path is fixed. Android does not look anywhere else.
Use the fingerprint of the key that signs the build users install. If you use Play App Signing, that is the app signing key shown in the Play Console, not your upload key. Debug builds use a different key, so list it as a second fingerprint while you test.
Yes. The file is an array. Add one statement per app, and list several fingerprints inside one statement when the same package ships with more than one signing key.
The usual causes are a redirect in front of the file, a fingerprint from the wrong key, a relation that is not handle_all_urls, and a device that cached a failed result. Our checklist covers the adb commands that show the verification state.
Serve application/json. Android may read other types, but a plain text or HTML type is the first thing to rule out when verification fails.
We host this file for you
Register your app in WarpLink and we generate, serve and update your assetlinks.json. Add a signing fingerprint in the dashboard and the file changes for you.