Link Opens in Browser Instead of App? Troubleshoot It

A link that looks like it belongs to your app can still open a browser. The cause may be the link’s host or path, a missing app, an incomplete domain association, a redirect, or a user or browser setting. This guide explains how iOS Universal Links and Android App Links work and gives you a practical way to narrow down the cause.

Key Takeaways

An ordinary HTTPS link opens a website unless the operating system has a valid association between that domain and an installed app.
iOS Universal Links and Android App Links use different association files and platform rules; configuring one does not configure the other.
Test the exact URL on a device with the app installed, then check the domain association and any redirects.
A redirect checker can reveal HTTP redirect behavior, but it cannot confirm app installation, operating-system verification, or what an in-app browser will do.

Three kinds of links that can look alike

Ordinary web links

A link such as https://example.com/products/42 is an HTTPS web URL. By itself, it does not tell a phone to open a particular app. If the device has no matching verified app association—or does not choose to use it—the browser handles the URL.

iOS Universal Links

A Universal Link is an ordinary HTTPS URL that iOS can route to an app when the app and website have a valid association. The app declares the domains it supports, and the website serves an Apple App Site Association file. The app also needs to handle the URL it receives.

The association is specific to an app identity and domain. A working association for www.example.com does not automatically cover example.com or links.example.com. Paths and app configuration matter too.

Android App Links

An Android App Link is an HTTPS deep link associated with an Android app and a website. The app declares matching URL patterns in its manifest, and the website publishes a Digital Asset Links file that identifies the app and its signing certificate. Android’s verification and user settings affect whether the link opens directly in the app.

These mechanisms are separate. A URL opening in an iOS app does not prove its Android configuration is correct, or vice versa.

Diagnose the link in this order

1. Record the exact URL that was tapped

Copy the URL from the link or message and note its scheme, hostname, path, and query string. For example, https://example.com/shop/item?id=42 is not the same host as https://www.example.com/shop/item?id=42.

Check that the URL uses https, and compare its hostname and path with the app’s configured domains and link patterns. Also check capitalization and any path restrictions in your platform configuration. If the link uses a branded short domain or a tracking domain, treat that as a different host until proven otherwise.

2. Confirm the app is installed and eligible to handle that URL

Test on a device with the intended app installed. If the app is absent, the browser is a normal fallback. If it is installed but the link opens the website, confirm that the app build on the device includes the relevant domain configuration and that its link handler supports the URL.

Test a known-good link for the same app as a comparison. If that opens the app but the problem URL does not, focus on differences in host, path, query handling, or redirects.

3. Check the website’s association file

For iOS, the site serves an Apple App Site Association file, commonly at https://example.com/.well-known/apple-app-site-association. It must be available for each domain you intend to support, and its app identifier and URL rules must match the app configuration. It is a JSON file without a .json extension.

For Android, the site serves https://example.com/.well-known/assetlinks.json. Its statements must identify the correct Android package and signing-certificate fingerprint. A mismatch between the published fingerprint and the installed build’s signing identity can prevent verification—for example, when testing a differently signed build than the one represented by the site file.

Check the exact hostname, file location, response status, and response body. Also inspect server or CDN rules that might block access, require authentication, or serve different content. Association files are not a substitute for the app’s own configuration: both sides must agree.

4. Inspect redirects and link wrappers

A short link, marketing redirect, or tracking URL may first point to a host that is not associated with the app. The final destination being associated does not guarantee that tapping the initial URL will open the app. For diagnosis, test a direct HTTPS URL on the intended associated domain, then compare it with the wrapped link.

A [Redirect Checker](Redirect Checker) can help reveal the HTTP redirect chain for a URL. It cannot tell whether the app is installed, whether iOS or Android has accepted the domain association, or whether a browser or messaging app will hand off the link. Some redirects may also depend on cookies, location, user-agent, or client-side JavaScript, so a checker’s result may differ from a real device’s navigation.

5. Test outside the original app or browser

Repeat the same direct link from a neutral test page or another app. The app where a user taps a link can affect the outcome: an in-app browser may keep navigation inside its own view or apply its own link-handling behavior. On iOS, user navigation choices can also affect whether a Universal Link stays in the browser, including the context of tapping a link on the same domain while browsing it.

Record the device model, OS version, app version, source app, and whether the link was tapped or pasted. Compare results rather than assuming every browser or messaging app behaves identically.

6. Check platform verification and user settings

On Android, check whether the domain is verified for the installed package and whether the user’s supported-link settings allow the app to open those links. Android’s verification behavior and available diagnostic commands vary by OS version. On supported devices, developers can inspect app-link state with Android Debug Bridge; for example:

adb shell pm get-app-links com.example.app

Replace com.example.app with the installed package name. Treat the output as a diagnostic clue, not a test of every browser or link source.

On iOS, confirm the app’s associated-domains entitlement, the website’s association file, and the app’s URL-handling code. Test a fresh installation as well as an existing installation when practical, because cached association or user-choice state can complicate diagnosis. Do not conclude that a server file alone proves the device has accepted the association.

A practical test matrix

Test	What it helps isolate
Direct URL, app installed	Whether the app and URL can be associated without a wrapper redirect
Same URL, app not installed	Whether the expected browser fallback works
Short or tracked URL versus direct URL	Whether the initial host or redirect flow changes handling
Link tapped from a different app	Whether the original browser or app affects navigation
Exact host and path compared with association rules	Whether the URL is actually covered by the configuration
Android verification state or iOS app and site configuration	Whether domain association is in place on the relevant platform

Change one condition at a time and keep the exact URLs and device details. That makes it easier to distinguish an association problem from a redirect or client-specific behavior.

Common Mistakes

Testing only the final destination. Users tap the initial URL, which may belong to a different host.
Assuming similar domains are interchangeable. example.com, www.example.com, and links.example.com are separate hosts for association purposes.
Checking only the website file. The app’s entitlement or manifest, URL patterns, signing identity, and link-handling code must also be correct.
Assuming a browser redirect checker can diagnose app handoff. It observes web responses; it does not emulate the installed app or operating-system association state.
Treating an in-app browser result as universal. Different source apps, user settings, and OS versions can affect what happens after a tap.
Testing a development build against production association data without checking its identity. Package identifiers, team identifiers, and signing certificates must match the published association configuration.

Best Practices

Test direct HTTPS links on every hostname you intend to support, including any www or branded-link subdomains.
Keep the app’s URL patterns and the website’s association files aligned, and verify files are publicly accessible over HTTPS.
Test on real devices with the app both installed and absent, and include the browsers and messaging apps your users actually use.
Keep a known-good direct URL for comparison with campaign, tracking, and short links.
Provide a useful web fallback. App links are not guaranteed to open an app in every context, and the website remains important for users without the app or when handoff is unavailable.
Use the official platform documentation for the precise file formats, configuration requirements, and OS-version behavior when implementing or changing associations.

Conclusion

When a link opens in a browser instead of an app, start with the exact URL and whether the app is installed. Then check the platform-specific domain association, redirects, and the context in which the link was tapped. These checks help identify what to fix without mistaking a web redirect test for proof of app-link behavior.

References

Platform setup details can change. Consult the current documentation for the OS versions and build configuration you support.

Why a Link Opens in the Browser Instead of Your App