What Is a Deep Link? Schemes, Universal Links, Intents
What is a deep link? The 3 mechanisms — URL schemes, universal links, Android intents — explained so your social links open the real app.


⚡ Zippy: a deep link is a link with places to be. it skips the lobby.
A deep link is a URL that opens a specific screen inside a native mobile app instead of a web page in a browser. There are 3 main mechanisms: custom URL schemes (the oldest), iOS Universal Links, and Android App Links / intents. Each one maps a tap to an installed app — with a web fallback when the app isn't there.
What is a deep link, exactly?
A deep link is any link that resolves to a location inside an app — a specific video, profile, product, or post — rather than to a website. A normal link says "open youtube.com in a browser." A deep link says "open the YouTube app, on this exact video."
The "deep" part matters. Launching an app to its home screen is shallow; landing the user three screens in, on the exact content they tapped, is deep. That difference is the whole game for anyone posting links on social platforms: the app is where your audience is logged in, has payment methods saved, and can actually subscribe, follow, or buy. The browser — especially the crippled in-app browser that social apps force your links into — is where those actions quietly fail.
How do custom URL schemes work?
A custom URL scheme is a made-up protocol an app registers with the operating system — the same slot https:// occupies, but owned by one app. When the OS sees a URL starting with that scheme, it hands the whole URL to the registered app, which parses the rest and navigates to the right screen.
Schemes are the oldest deep-linking mechanism, and they have two famous weaknesses:
- No built-in fallback. If the app isn't installed, a raw scheme URL just… does nothing. Whoever fires it has to detect the failure themselves and redirect to the web — usually with a short timer: try the scheme, and if the app hasn't taken over within a beat, fall back to the browser. This is exactly how Zippy handles iOS: app URL scheme first, timed fallback to the web second.
- No ownership check. Any app can claim any scheme. Two apps can register the same one, and the OS picks. That's why Apple and Google both built successors.
The honest upside: schemes work from almost anywhere, including contexts where the fancier mechanisms get stripped. That's why they're still load-bearing in 2026.

⚡ Zippy: the oldest trick in the book is still in the book because it works.
What are Universal Links and App Links?
Universal Links (iOS) and App Links (Android) are normal https:// URLs that the operating system associates with an app, using a verification file hosted on the domain. Tap one, and the OS checks: is the app for this domain installed? If yes, open the app at that content. If no, open the URL in the browser like any other link — the fallback is built in.
This design fixes both scheme problems at once. The link is a real web URL, so it never dead-ends. And the domain association file proves ownership, so no other app can hijack your links.
The catch — and it's a big one for social traffic — is that Universal Links are fragile in exactly the places you post. In-app browsers and webviews frequently refuse to trigger the app-open, treating the link as a plain web URL. So the "modern, correct" mechanism often silently degrades into the very webview experience you were trying to escape. That's why real-world deep linking on social still leans on schemes and intents.
How do Android intents work?
An intent is Android's native message format for "someone should handle this action" — and intent:// URLs let a web link speak it directly. An intent URL names the target app's package, the content to open, and — this is the elegant part — a built-in fallback URL the browser uses if the app isn't installed.
That makes intents the most robust deep-link mechanism on Android: one URL that says "open the app if you can, this web page if you can't," with no timers and no guesswork. It's what Zippy fires on Android — intent:// URLs with the native fallback baked in.
How do the three mechanisms compare?
| Custom URL schemes | Universal Links / App Links | Android intents | |
|---|---|---|---|
| Platform | iOS + Android | iOS / Android | Android only |
| Looks like | appname://... | Normal https:// URL | intent://... |
| Fallback if app missing | None built in — needs a timed fallback | Automatic (opens the web URL) | Built into the URL itself |
| Ownership verified | No | Yes (hosted file on the domain) | Yes (package name) |
| Works from in-app browsers | Usually | Often blocked or ignored | Usually |
| Best for | iOS escapes from webviews | Links tapped in real browsers | Android escapes from webviews |
The pattern to notice: the mechanisms that survive in-app browsers (schemes, intents) are not the ones with the cleanest fallbacks, and vice versa. Doing deep links right means picking per platform, per context — and keeping that routing current as apps change behavior.
Why do deep links matter so much for social links?
Because every major social app — Instagram, TikTok, LinkedIn, X, Reddit, WhatsApp — opens your links in its own embedded webview, where your audience is logged out, tracking pixels land in a sandboxed cookie jar, and checkouts choke. We've written up the full anatomy of why links die in the in-app browser, and the short version is: the tap happens, the conversion doesn't.
A deep link is the escape hatch. Route the tap into the native app — where the follow button works because the user is actually signed in — and the conversion you already earned gets to complete. It also rescues your data: attribution pixels that never fire in the webview fire fine in a real context.

⚡ Zippy: you did the hard part. someone tapped. don't lose them in the lobby.
What happens when a deep link fails?
A properly built deep link degrades to opening the destination in the browser — it never becomes a broken link. A wrong or outdated scheme on iOS just means the timed fallback kicks in and the web page loads. An intent URL with no matching app opens its fallback URL. Failure mode is "slightly worse experience," never "dead tap."
That's the standard Zippy holds itself to, plus one more: permanence. A Zippy link never stops redirecting — not on the free plan, not after a trial ends, not after you cancel. Over-limit links go read-only but keep redirecting on the same slug, forever.
Do you need to build deep links yourself?
Only if you enjoy maintenance. The mechanisms above are public and documented — the redirect engine Zippy runs is open source under AGPL (Cloudflare Workers + KV, self-hostable), so you can read exactly how the routing works and run it yourself.
What you're really signing up for is upkeep: every platform has different scheme behavior, iOS and Android need different escapes for the same destination, and apps change things without notice. The hosted product exists so a scheme change shows up in our routing table, not in your conversion graph. Free plan (Sidekick) gives you 5 active links forever; Hero is $19/mo — or $180/yr, which works out to a flat $15/mo — with unlimited links, unlimited never-metered clicks, and full analytics. There's a 14-day full Hero trial, no credit card.
FAQ
What is a deep link in simple terms?
A deep link is a link that opens a specific screen inside a mobile app instead of a web page. Tap a deep link to a YouTube video and the YouTube app opens on that video — not youtube.com in a browser tab. If the app isn't installed, a well-built deep link falls back to the web page.
What's the difference between a deep link and a universal link?
"Deep link" is the umbrella term for any link that opens app content. A Universal Link is one specific iOS mechanism for doing it: a normal https URL that iOS associates with an app via a verified file on the domain. All universal links are deep links; not all deep links are universal links.
Do deep links work if the app isn't installed?
They should fall back to the web, and the good mechanisms make that automatic. Universal Links open the URL in the browser; Android intent URLs carry a fallback URL inside them; raw URL schemes need whoever fires them to add a timed fallback. Either way the user lands somewhere useful — never on a dead tap.
Why don't my links open the app from Instagram or TikTok?
Because those apps intercept your links into their own in-app browser, and plain https links — even Universal Links — usually stay trapped there. Escaping takes the right mechanism for the right OS: URL schemes with timed fallback on iOS, intent URLs on Android. That per-platform routing is exactly what a Zippy link does on every tap.
Stop losing taps you already earned — make your links open the real app at zipthe.link.