Check your deep link setup

Enter your domain and we test the Apple and Android files together: the fetch, the headers, the app identifiers and the paths that should open your app.

Results appear here.
Enter a domain above and press Enter or Check setup. We test the Apple file, the Android file and your domain together.

What this checks

HTTPS and status: Both files must answer 200 over HTTPS on the exact host in your app settings.
No redirects: iOS and Android read these files without following redirects, including apex to www.
Headers: Content type and size, for the Apple file and the Android file.
apple-app-site-association: Valid JSON, applinks details, App ID format, and the path rules that match your sample path.
assetlinks.json: The relation, the package name and each SHA-256 signing certificate fingerprint.
App identifiers: Optional Team ID, bundle ID and package name, compared with what the files declare.
Sample path: A path such as /products/42 is matched against the path rules in your AASA file. On Android, path rules live in your app's manifest, not in assetlinks.json.

How to read the report

The verdict: The headline takes the worst status of the three sections, so one failed check turns it red. The counts under it add up every check once.
The iOS section: The Apple file as a phone reads it, then each App ID and your example path matched against the rules. Failing checks come with a fix and the lines to add.
The Android section: assetlinks.json as Android reads it, then each package name and SHA-256 certificate fingerprint you entered, looked up in the statements.
Domain and HTTPS: The connection, the certificate, and the redirect and content type of each file. These checks sit here once, so they are not counted twice.
What we matched: For each App ID: the entries that list it, whether it uses appIDs or the older appID key, and the rule that opened or blocked your path. For each package: the relation and which fingerprints are listed.
Next steps: Open the full AASA or assetlinks report for the raw file, generate a corrected file from what we found, or set up your app once everything passes.

Error reference

The messages below appear in the report. Find the one you see, then make the change in the last column.

What the report says	Cause	Fix
No DNS record answered for your domain	The domain is misspelled, or its A, AAAA or CNAME record does not exist yet.	Check the spelling, add the record, and wait for DNS to finish updating.
The secure connection failed	The certificate is expired, self-signed, or issued for another name.	Install a certificate from a public authority for this exact host and serve the full chain.
The server answered 404	The file is not at /.well-known/apple-app-site-association or /.well-known/assetlinks.json on this host.	Serve the file with status 200 at that path, on the exact host your links use.
The request answered 301 or 302 and sent us elsewhere	Your server redirects http to https, the apex to www, or every path to a login page. Apps do not follow the redirect.	Serve the file directly on the host in your links, and exempt /.well-known/ from the redirect rule.
Served as text/html or with no content type	The server sends its default type for a file with no extension.	Send the header Content-Type: application/json for both files.
The App ID is not listed in applinks.details	The Team ID or bundle ID differs from the file, or the letter case does not match.	Add the App ID, written exactly as TEAMID.bundle.id, to the appIDs list of the entry that holds your rules.
The path matches none of the AASA rules	No components or paths rule covers the link, so iOS keeps it in the browser.	Add a rule for the path to the entry that lists your App ID.
An exclusion rule blocks the path	An exclude component or a NOT path covers the link before a rule can allow it.	Remove the exclusion, or narrow it so it no longer covers this path.
The package is not listed, or handle_all_urls is missing	No android_app statement names the package, or its statement lacks the relation that grants link handling.	Add a statement with the package name and the relation delegate_permission/common.handle_all_urls.
A SHA-256 fingerprint is not listed	The build is signed with a key the file does not list. Google Play re-signs with its own app signing key.	Add the fingerprint from Play Console under App signing, and keep your upload key for local builds.

What a deep link check can tell you

A deep link works when four things agree: the file on your domain, the identifiers in your app, the rules for the path, and the response your server sends. This checker reads the first, the third and the fourth from your public domain, and compares the second when you enter your identifiers.

A web check tests what iOS and Android download. Opening the app on a device is the last test, and our guide on testing deep links lists the commands. Apple also serves files from its own CDN, so a change can take time to reach a fresh install.

The domain is the only required field. Add your identifiers to compare them with the files. An iOS App ID is your Team ID, a dot and your bundle ID: the Team ID is on the Membership page of your Apple Developer account, and the bundle ID is in your Xcode target. An Android package name is the applicationId in your Gradle file. The SHA-256 certificate fingerprint is in Play Console under App signing, or in the output of the Gradle signingReport task.

Frequently asked questions

What does this checker test?

It fetches /.well-known/apple-app-site-association and /.well-known/assetlinks.json from your domain, then checks the status, redirects, headers, JSON, app identifiers and the AASA path rules. The report has one section for each platform.

Can it confirm my app opens?

It confirms the files that decide whether your app opens. Tapping a link on a device confirms the rest, because the operating system also checks your app's entitlements and signing.

Why does a valid AASA file still fail?

The file is one of several inputs. The Associated Domains entitlement, the Team ID in the App ID, a cached older copy on the device and a link typed into the address bar can each stop Universal Links from opening the app.

Which signing certificate does Android need?

The certificate that signs the build the user installs. For apps distributed through Google Play, that is usually the app signing key shown in Play Console, not your local upload key. List both while you test.

Do subdomains need separate files?

Yes. Each host in your app's Associated Domains and Android intent filters serves its own copy of each file. Check every host you use, including the one in your shared links.

What does the example link path do?

It is tested against the rules in your AASA file. The report names the rule that matched, or the exclusion that blocked it, and whether your App ID is listed in that entry. Enter a path from a real link, such as /products/42.

Does the checker change anything on my domain?

No. We request your two public files over HTTPS and read the responses. We write nothing to your server, and we do not need an account or a login.

Related tools

We host these files for you

Register your app in WarpLink and we generate, serve and update your apple-app-site-association and assetlinks.json files. You stop maintaining them by hand.

Start buildingFree to start. No sales call.