Skip to content
Free tools

Deep link checker

Does your deep linking actually work?

This deep link checker fetches a domain’s apple-app-site-association (AASA) file for iOS Universal Links and its assetlinks.json for Android App Links, and checks HTTPS, redirects, content type, JSON validity, app IDs, the handle_all_urls relation, package name and SHA-256 fingerprints. It names the exact check that fails.

  1. Enter the domain your links are served from
  2. Select Check
  3. Fix each failed or warning row, then check again

Try

iOS · Universal Links (AASA)

/.well-known/apple-app-site-association

  • Served over HTTPS with 200
  • No redirect
  • Content-Type is application/json
  • Body is valid JSON
  • applinks.details is present
  • App IDs are well formed
Android · App Links (assetlinks.json)

/.well-known/assetlinks.json

  • Served over HTTPS with 200
  • Body is a valid JSON array
  • Relation handle_all_urls present
  • package_name present
  • SHA-256 fingerprints well formed

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
SwiftURL deep linking settings: enter your Apple Team ID and Bundle ID and your Android package name and SHA-256 fingerprints, and SwiftURL generates and serves the association files.

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.