Skip to content
← Free tools

Deep link checker

Does your deep linking actually work?

Enter a domain and this tool validates both sides of app-link setup in one pass: the Apple App Site Association file for iOS Universal Links, and assetlinks.json for Android App Links. It tells you what is broken and how to fix it.

Try ·

Tired of hand-maintaining these files? SwiftURL generates and serves both the AASA and assetlinks.json for you, on your own branded domain, so Universal Links and App Links just work.

How SwiftURL does it

What this checker looks at, and why

A universal or app link is a normal web URL that, when tapped on a phone, opens straight into your mobile app instead of the browser. Two files make that work, and both have to be exactly right or the link quietly falls back to the web. This tool fetches both and checks the things that actually break in practice.

iOS: apple-app-site-association (AASA)

iOS reads a file at /.well-known/apple-app-site-association to learn which apps may open your links. It must be served over HTTPS, return HTTP 200, and contain valid JSON with an applinks.details block. The single most common failure is a redirect: Apple does not follow redirects when fetching this file, so a 301 or 302 that looks harmless in a browser will stop Universal Links dead. The path must also carry no .json extension, and each app identifier must be well formed as a ten-character Team ID, a dot, then the bundle identifier. The checker verifies each of these and points at the specific one that is wrong.

Android: assetlinks.json

Android reads a Digital Asset Links file at /.well-known/assetlinks.json. It has to be a JSON array of statements, at least one of which grants the relation delegate_permission/common.handle_all_urls, names your package_name, and lists your app signing certificate as SHA-256 fingerprints in uppercase, colon-separated hex. A frequent mistake here is pasting the fingerprint from the wrong signing key, or in the wrong case, so App Links verify on one build and fail on another.

Why both matter for deferred deep linking

Direct deep linking sends an existing app straight to the right screen. Deferred deep linking preserves that destination across a fresh install, so a first-time user still lands where the link intended after they download the app. Both rely on these association files being correct on the domain that hosts the link. If you serve your links from a branded domain, the well-known files must live on that same domain, which is exactly the part teams forget. This tool checks the domain you actually send links from, not a placeholder, so what you validate is what your users hit.

If you would rather not maintain any of this by hand, SwiftURL generates and hosts both files for you on your own domain, and keeps them in sync as your app configuration changes. See deep linking and deferred deep linking.

Frequently asked questions

Why are my Universal Links not opening the app?
The most common cause is a redirect on the AASA file. Apple does not follow redirects when fetching apple-app-site-association, so a 301 or 302 makes Universal Links silently fail. Other causes are a wrong content type, invalid JSON, or a malformed appID, all of which this checker flags.
Where should the AASA file be hosted?
Serve it at https://yourdomain.com/.well-known/apple-app-site-association over HTTPS, returning HTTP 200 with no redirect and no .json extension on the path. The body must be valid JSON with an applinks.details block.
What format do assetlinks.json fingerprints need?
Android App Links need sha256_cert_fingerprints as uppercase, colon-separated hex pairs. The statement must use the relation delegate_permission/common.handle_all_urls and include the package_name.
Does this tool store the domains I check?
No. The check runs on demand and results are cached briefly at the edge only to avoid re-fetching the same domain on repeated checks. There is no signup and nothing is saved to an account.
Does SwiftURL host these files for me?
Yes. SwiftURL generates and serves both the AASA and assetlinks.json files for you on your own branded domain, so deep linking and deferred deep linking work without you hand-maintaining the well-known files. See deep linking.