Mobile Deep Link Generator & Validator
Generate and validate Android App Links, iOS Universal Links, and more.
Configure Android App Links, iOS Universal Links, Flutter, React Native, and Expo deep linking, then generate assetlinks.json, apple-app-site-association, manifest and entitlement snippets, test commands, and a QR code — all validated and generated locally in your browser.
What is mobile deep linking?
A deep link is a URL that opens a specific screen inside a mobile app instead of (or in addition to) a website — for example, a link to a product, an order, or a password-reset screen. There are three common ways to implement one:
Custom URI schemes (like myapp://product/123) are the simplest to set up but aren't verified by the OS — more than one installed app can register the same scheme, and there's no safe fallback if no app claims it.
Android App Links use standard HTTPS URLs that Android verifies against a assetlinks.json file hosted on your domain, so only your verified app can open them — with the browser as an automatic fallback.
iOS Universal Links work the same way on Apple platforms, verified against an apple-app-site-association file instead.
Deferred deep linking — routing a user to the right screen even after installing the app from a store — needs attribution infrastructure and persistent server-side storage. This tool generates standard deep-link configuration and files only; it does not provide deferred-link hosting or attribution.
App Links vs Universal Links vs custom schemes
| Type | Platform | URL format | Domain verification | Fallback behavior | Security | Best use case |
|---|---|---|---|---|---|---|
| Android App Links | Android | https://example.com/path | Server-side, via assetlinks.json + autoVerify | Opens the browser at the same URL if unverified or uninstalled | Strong — domain-verified, can't be claimed by another app | Production links shared publicly (email, ads, social) |
| iOS Universal Links | iOS | https://example.com/path | Server-side, via apple-app-site-association | Opens Safari at the same URL if unverified or uninstalled | Strong — domain-verified, can't be claimed by another app | Production links shared publicly (email, ads, social) |
| Custom URI scheme | Android & iOS | myapp://path | None — first app registered for the scheme wins | Fails silently or shows an OS error if no app claims the scheme | Weak — any app can register the same scheme | In-app navigation and internal links, not untrusted public links |
Setup workflow
- 1
Configure your identifiers and domain in the Configure tab — app name, package name, bundle ID, and website domain.
- 2
Generate the platform files you need in the Generated Files tab.
- 3
Upload assetlinks.json and apple-app-site-association to the exact hosting paths shown for each file.
- 4
Add the generated manifest, entitlement, and Info.plist snippets to your native app configuration.
- 5
Build and sign your application with the certificate whose SHA-256 fingerprint you used.
- 6
Test on a physical device using the adb or simctl commands from the Test Link tab.
- 7
Verify fallback behavior by uninstalling the app and confirming the link falls back to your website.
Common mistakes
- Using the debug SHA-256 certificate fingerprint in a file meant to verify a release build (or vice versa).
- Hosting .well-known/assetlinks.json or apple-app-site-association behind a redirect — both must be served directly with a 200 response.
- Serving assetlinks.json with the wrong Content-Type instead of application/json.
- Publishing invalid JSON — a single trailing comma or missing bracket breaks verification silently.
- Using the wrong Apple Team ID or bundle ID in the AASA app ID (must be exactly TEAMID.bundle.id).
- Naming the AASA file apple-app-site-association.json — it must have no file extension at all.
- A mismatch between the domain configured in the app and the domain actually hosting the verification file.
- Assuming a cached verification result will update immediately — both platforms cache aggressively.
- Not rebuilding and reinstalling the app after changing manifest, entitlement, or plist configuration.
- Trusting query parameters or tokens from a deep link without validating them server-side.
Need help implementing deep links in your mobile app?
92 Nodes can configure, test, and integrate secure deep linking for Flutter, React Native, Android, and iOS applications.
Common questions
What is the difference between a deep link and a Universal Link?+
A deep link is the general concept of a URL that opens a specific screen in an app. A Universal Link is Apple's specific, domain-verified implementation of that concept using standard HTTPS URLs — as opposed to a custom URI scheme, which isn't verified and can be claimed by more than one app.
Where should I upload assetlinks.json?+
At https://yourdomain.com/.well-known/assetlinks.json, served over HTTPS with a Content-Type of application/json and no redirects.
Does the AASA filename include .json?+
No. The file must be named exactly "apple-app-site-association" with no file extension. Adding .json is one of the most common setup mistakes.
Why does my App Link open in the browser?+
Usually because domain verification failed — the hosted assetlinks.json or AASA file is missing, unreachable, malformed, or doesn't match your package name/bundle ID and signing certificate. It can also happen if autoVerify is off or the app hasn't been reinstalled since the configuration changed.
Can I test a deep link without publishing the app?+
Yes. Install a debug or internal test build on a device or simulator, then use the adb (Android) or simctl (iOS) commands from the Test Link tab to open the link directly.
How do I find my Android SHA-256 fingerprint?+
Run keytool -list -v -keystore your.keystore and look for the SHA-256 line, or find it in the Google Play Console under App integrity for a release build already published there.
Can one domain support multiple mobile apps?+
Yes — assetlinks.json accepts multiple statements (one per app), and an AASA file's applinks.details array can list multiple app IDs, each scoped to different path components.
Does this tool provide deferred deep linking?+
No. This tool generates standard deep-link configuration and files. Deferred deep linking (routing a user correctly even through an app store install) requires attribution infrastructure and persistent server-side storage that a browser-based tool can't provide.
Is my configuration uploaded to 92 Nodes?+
No. Everything — generation, validation, and the QR code — runs entirely in your browser. Nothing you enter is sent to a server, and your configuration is only saved to your own browser's local storage.
Are custom URL schemes secure?+
Not on their own. Any app can register the same custom scheme, so another app could intercept links meant for yours. Use HTTPS App Links and Universal Links for anything security-sensitive, and reserve custom schemes for internal navigation.
Looking for the mobile app development itself, not just the deep-link configuration? See our mobile app development service.
More free resources
Have a project in mind? Let's build it.
Tell us about your goals and we'll get back to you within one business day with next steps.
Book a free call