A link can lead to the same web address and still open an app on your phone but a website on your computer. The difference is usually how the operating system and browser handle that address—not a different link. This guide explains ordinary links, deep links, and app links, then gives you a repeatable way to investigate the behavior on different devices.
Key Takeaways
- An ordinary
https://link opens a web address; a phone may route that address to an installed app if the app and domain are associated. - Deep links can point into an app, but custom URL schemes are not the same as verified web links and may behave differently across devices.
- Installation, browser context, operating-system preferences, link redirects, and app configuration can all affect the result.
- Test the exact same URL on each device and record the device, browser, app-install state, and how you opened the link.
What kind of link are you testing?
An ordinary web link uses a scheme such as https:// and identifies a page on a website:
<a href="https://example.com/products/42">View product</a>
A deep link is a link intended to take a user to a particular screen or item inside an app. It may use an app-specific URL scheme, such as myapp://products/42, or an ordinary web URL that the app is configured to handle. A custom scheme may not have a useful destination if the app is not installed, and another app could potentially register for the same scheme.
App links are web URLs that a platform can associate with an app and a website. Android App Links and Apple Universal Links use platform-specific association mechanisms. When the association is set up and recognized, a supported mobile device can open the app for a matching web URL. On a computer without that mobile app association, the browser normally opens the website.
That means the address visible in the link can be identical even when the destination application differs.
Why the same URL behaves differently
The app is installed and associated with the website
A phone can hand a matching web URL to an installed app. Android App Links depend on app configuration and verification of the website association. Apple Universal Links likewise require the app and website to be configured for the relevant domains. A link that is not associated—or a URL path that is outside the app's configured scope—may stay in the browser.
An app being installed is not, by itself, proof that every link to its company’s website should open in that app.
The user or browser has a different preference
People can change supported-link or default-app preferences, and operating-system behavior may vary by version and device configuration. The browser also matters: opening a link from a messaging app, social network, email client, or an in-app browser may behave differently from tapping it in the phone’s default browser. Some apps display the page in their own browser instead of handing it to the operating system.
The link redirects or changes form
A short link, tracking redirect, or redirect to a different hostname can affect whether the destination is eligible to open in an app. Association is tied to domains and app configuration, so do not assume a link to one host behaves like a link to another. Compare the original URL with the final URL after redirects.
The desktop and phone are not equivalent environments
A computer may not have the mobile app, the same domain association, or the same link-handling integration. Desktop browsers also have their own extensions and settings. A desktop result therefore does not establish what a phone should do, and one phone’s result does not guarantee that every phone will behave the same way.
A reproducible troubleshooting checklist
Use a controlled comparison rather than testing from memory:
- Copy the exact link. Record the full URL, including its scheme, hostname, path, query string, and any tracking parameters. Avoid comparing a shortened link on one device with a direct link on another.
- Test on desktop. Open the link in a normal browser tab and note the browser, URL before and after redirects, and final page.
- Test on mobile with the app installed. Tap the link from the same source app and then, if possible, try the phone’s browser. Record whether it opens the app, a browser tab, or an in-app browser.
- Test with the app absent, if practical. Use a test device or a safe test environment. Note whether the web page loads, the app store opens, or the link fails. Do not uninstall an app or clear data if doing so risks losing user information.
- Compare link sources. Try the same URL from a plain HTML page, a message, and the browser address bar. A difference can point to the source app’s in-app browser or link-handling behavior.
- Check the final destination. Follow redirects and note every hostname change. Confirm that the intended mobile app is configured for the final domain and the relevant URL paths.
- Repeat on another device or OS version. Record model, OS version, browser version, app version, install state, and relevant link preferences. Results may differ across configurations.
- Check platform association setup. For Android, review the App Links configuration and website association. For Apple platforms, review Universal Links configuration and the domain association. Confirm that the test URL falls within the configured domain and path scope.
A useful test record might look like this:
URL: https://example.com/products/42
Device: Android phone, OS version recorded
Browser/source: messaging app, then default browser
App installed: yes
Result: app opens from message; browser opens from address bar
Redirects: none observed
If only one source app behaves differently, investigate that app’s browser or link-handling behavior first. If every browser leaves the link on the website, check the app association, verification status, and URL scope. If behavior changes after a redirect, test the final URL directly as well as the original link.
Platform-specific considerations
On Android, an HTTPS link can be handled as an App Link when the app declares matching web addresses and the website proves its association with that app. Verification, user preferences, Android version, and the URL being tested can affect the result. An ordinary intent filter should not be treated as equivalent to a successfully verified App Link.
On Apple platforms, Universal Links associate a website domain with an app. The app’s associated-domains setup and the website’s association file must agree. User actions and the context in which a link is tapped can also influence whether it opens in the app or browser.
Platform setup and settings can change over time. I cannot live-check official documentation in this writing environment, so confirm current configuration steps and version-specific behavior in the official Android and Apple references below before changing a production app.
Common Mistakes
- Assuming every HTTPS link is an app link. A normal web URL opens an app only when the platform can route it there under the relevant configuration and preferences.
- Testing only with the app installed. Include an app-not-installed case where feasible; it reveals whether the web fallback works.
- Using different URLs in each test. Redirects, hostname aliases, query parameters, and URL paths can change the outcome.
- Treating a custom scheme as a universal fallback. It may fail when the app is absent and can be claimed by another app. Provide a dependable web destination.
- Concluding that a platform is broken after one test. Repeat with the same URL in different sources and on another device before diagnosing a platform-wide issue.
- Ignoring in-app browsers. A social or messaging app may keep a link inside its own browser rather than invoking the system’s normal link-handling flow.
Best Practices for Website Owners
- Keep the web page useful and accessible even when the app is not installed.
- Use platform-supported web-link associations for domains you control, and configure only the domains and paths the app should handle.
- Test both app-installed and app-not-installed flows, as well as redirects and links from common source apps.
- Avoid relying solely on custom URL schemes for links shared outside your app.
- When reporting a bug, include the exact URL, redirect chain, device and OS, browser or source app, app version, install state, and observed result.
Conclusion
When a link opens an app on a phone but a website on a computer, the URL may be the same while the devices’ app associations and link-handling contexts differ. Compare the exact URL, redirects, source app, installation state, and platform configuration to find where the behavior diverges.
References
These are official documentation references for platform-specific setup. I have not live-verified their current contents here; check them for up-to-date details.