Deep linking
Send each visitor
where the link actually works.
A deep link opens a specific place inside an app instead of a browser tab. Done properly it's the best experience you can give a mobile visitor. Done carelessly it's a tap that goes nowhere.
- Device-aware routing
- Guaranteed web fallback
- Open-redirect protection
The landscape
Three link formats, constantly confused for each other
"Deep link" gets used for all of these interchangeably, which hides the fact that they fail in completely different ways. Universal links and Android app links share a column below — they are the same idea on two platforms, and the explainer splits them out.
| Custom scheme | Universal / app link | Android intent URL | |
|---|---|---|---|
| Looks like | app://path | https://… | intent://…#Intent;…;end |
| Domain setup required | No | Yes | No |
| Ownership verified | No | Yes | No |
| If the app isn't installed | Fails, often silently | Loads the web page | Goes to the fallback URL |
| Survives an in-app browser | Often blocked | Sometimes | Usually |
The full breakdown — including what an apple-app-site-association file and an assetlinks.json actually do — is in the deep-linking explainer.
The rule
Never treat a native launch as guaranteed
The app may not be installed. The scheme may have changed in an update. The webview may block the navigation. The visitor may be on desktop. Every one of those is normal, not exceptional — so the correct structure is a chain, not a destination.
- 01
Attempt the native target
Only where it makes sense: a mobile OS, and a known app for this destination. A creator-set app URL takes priority over the catalog match.
- 02
Fall back to the web URL
The same content, on the web. This step always exists, so the visitor lands where they meant to go whether or not the app was there.
- 03
Never confirm success from the tap
There's no reliable callback telling a web page that an app launched. Analytics that count taps as app opens are overstating the number, and we don't.
In OpenOut
Five routing modes, set per link
Each link on your page carries its own routing mode, so a Spotify link and a checkout link don't have to behave the same way.
Standard
Open the web URL. No native attempt at all — the right default for anything that doesn't have an app worth opening.
Smart
On mobile, resolve the destination against the app-target catalog and attempt the native link; otherwise go straight to the web URL.
Native app
Prefer the app explicitly. Same fallback chain as smart mode, but the intent is unambiguous rather than inferred from the destination.
External browser
Route the visitor out of a restricted in-app browser first, before doing anything else with the destination.
Guide
Show the visitor the manual instructions directly — the transparent path for cases where nothing automatic is going to work.
Safety
Every destination is validated before it's used
A deep-link resolver that will follow any URL handed to it is an open redirect, and open redirects get abused for phishing. OpenOut checks each candidate before it ever reaches a navigation:
- Only http(s) and known-safe app schemes pass — never javascript: or data:
- The destination host has to belong to the link, not to whatever a query parameter asks for
- Creator-set app URLs go through the same guard as catalog-resolved ones
FAQ
Straight answers
What is a deep link?
A URL that points at a specific place inside an app rather than at its home screen — a particular album, product, chat or profile. The concept is simple; the confusion comes from the several different technologies that implement it, each with different failure modes.
What's the difference between a deep link and a universal link?
"Deep link" is the general concept. A universal link is Apple's specific implementation using verified HTTPS URLs, which requires an apple-app-site-association file on your domain and an entitlement in the app. Every universal link is a deep link; not every deep link is a universal link.
Do deep links open Safari or Chrome?
No — that's a different problem. A deep link routes a URL to an app. Getting a visitor out of an in-app browser and into their system browser is a separate flow, which is what the breakout engine handles.
What happens if the app isn't installed?
It depends on the link type. Custom URL schemes typically fail, often silently. Universal links and Android app links load the equivalent web page. Android intent URLs go to whatever fallback URL you specify. OpenOut always keeps the web URL as the final step, so the visitor is never stranded.
Is a deep-link redirector a security risk?
It can be. A resolver that follows any URL handed to it is an open redirect, which gets abused for phishing. OpenOut validates every candidate before use — only http(s) and known-safe app schemes pass, and the destination host has to belong to the link.
Can I track whether the app actually opened?
Not reliably from a web page, and no honest tool will tell you otherwise. Meaningful measurement has to come from an event on the other side — inside the app or on the destination page.
Keep reading
TikTok in-app browser
Why TikTok's built-in browser breaks logins, checkout and downloads — and how to get visitors out of it.
Instagram in-app browser
What Instagram's in-app browser does to your link in bio, and what actually works as a fix.
Deep links, universal links and app links explained
Four terms, constantly used interchangeably, that behave very differently in practice. Here is the distinction that matters — and the one rule that keeps deep links from breaking.
Route every link properly
Per-link routing modes, a guaranteed web fallback, and a breakout flow for visitors stuck in an in-app browser.
Start free