A deep link is a URL that opens a specific screen inside a mobile app rather than the app's home screen. Tapping a deep link to a product, profile, or article takes the user straight to that item, the same way a web URL points at a specific page rather than a site's front page.

What is the difference between a deep link and a universal link?

Deep linking is the general concept; universal links are Apple's implementation of it. An iOS universal link is a standard https:// URL that opens your app when installed and falls back to your website when not, verified through an apple-app-site-association file hosted on your domain. Android's equivalent is App Links, verified with an assetlinks.json file.

What is the difference between deep linking and deferred deep linking?

A standard deep link only works if the app is already installed — if it isn't, the link falls back to the web or an app store page and the original destination is lost. Deferred deep linking preserves that destination across the install, so a new user who installs the app lands on the intended screen the first time they open it.

Do deep links work if the app is not installed?

A plain deep link does not. It will fall back to your website or the app store, and the specific destination is discarded. To route a brand-new user to the right screen after they install, you need deferred deep linking, which stores the intended destination and delivers it on first app open.

Why do my deep links open the browser instead of the app?

The most common causes are a missing or malformed apple-app-site-association or assetlinks.json file, the file being served with the wrong content type or behind a redirect, a mismatched team ID, bundle ID, or SHA-256 fingerprint, or Apple's CDN still serving a cached copy of an older file. A deep link debugger will identify which of these is failing.

Do I need an SDK to use deep links?

Not for basic routing — iOS and Android can handle universal links and app links natively once the association files are in place. An SDK becomes necessary for deferred deep linking, install attribution, and campaign analytics, because those require matching a pre-install click to a post-install app open.

Glossary/Implementation artifacts

What is deep linking?

Definition

Deep linking is the practice of using a URL to open a specific screen or piece of content inside a mobile app rather than the app's default entry point.

The idea is old — it is what a URL has always done on the web — but on mobile it takes four different mechanisms to deliver, and which one applies depends on the platform, whether the app is installed, and where the tap happened. This page is the map: what each mechanism is, when each is used, and which page covers it in depth.

The four mechanisms

"Deep link" is the umbrella term. Underneath it are four distinct mechanisms with different guarantees, and most confusion in this area comes from using one word for all of them.

The four deep linking mechanisms, and what each one guarantees.
Mechanism	Platform	Format	Ownership verified	App not installed
Universal Link	iOS	`https://`	Yes — AASA file	Opens the website
App Link	Android	`https://`	Yes — assetlinks.json	Opens the website
Custom URI scheme	Both	`myapp://`	No — any app can claim it	Error
Deferred deep link	Both	`https://`	Inherits the link's	Store, then routes after install

The same destination, expressed in each form. Only the first two prove that the app is allowed to handle the URL, which is why they are the only ones safe to publish to users:

One product page, four ways

# Universal Link / App Link — the same HTTPS URL on both platforms
https://example.com/products/42?utm_source=email

# Custom scheme — no verification, fails if the app is missing
shopapp://products/42

# Android intent:// — scheme plus a web fallback in one URL
intent://products/42#Intent;scheme=https;package=com.example.shop;
S.browser_fallback_url=https%3A%2F%2Fexample.com%2Fproducts%2F42;end

# Deferred — the same HTTPS URL, with the destination preserved
# through the store install by the referrer or a first-launch match
https://links.example.com/p/abc123

What decides where a tap lands

Three variables: the platform, whether the app is installed, and the context the tap happened in. The third is the one that surprises people — the same link behaves differently in Safari, in Gmail, and inside Instagram's browser.

Where one HTTPS link lands, by platform and install state.
Platform	Installed	Destination	Depends on
iOS	Yes	The app, on the right screen	AASA file plus the Associated Domains entitlement
iOS	No	The web page, then the App Store	Your fallback chain
Android	Yes	The app, on the right screen	`assetlinks.json` plus a verified intent filter
Android	No	The web page, then Play	Your fallback chain
Either, in an in-app browser	Yes	Frequently the webview, not the app	The host app's webview policy
Desktop	n/a	The web page	Nothing

The context column is where most real failures live

A link that works from Messages and fails from Instagram is not misconfigured — it is being intercepted by a webview that never asks the OS to resolve it. The same applies to email clients that wrap every URL in a click-tracking redirect. Both are covered in depth on their own pages.

What it takes to ship

Two files, two declarations, and a routing function. No SDK is required for the basics — iOS and Android both handle verified HTTPS links natively once the association files are in place.

The minimum viable setup, per platform.
	iOS	Android
File on your domain	`/.well-known/apple-app-site-association`	`/.well-known/assetlinks.json`
Declaration in the app	Associated Domains entitlement	Intent filter with `autoVerify`
Identifier it carries	App ID Prefix plus bundle ID	Package name plus SHA-256 fingerprint
When it is checked	At install, via Apple's CDN	At install, by the verification agent
Entry point in code	`NSUserActivity` with `webpageURL`	`Intent.data` on the activity
Verification is inspectable	`swcutil dl -d yourdomain.com`	`adb shell pm get-app-links <package>`

Test both platforms in four commands

# Android: fire the intent a browser would fire
adb shell am start -W -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE \
  -d "https://example.com/products/42"

# Android: is the domain actually verified
adb shell pm get-app-links com.example.shop

# iOS: what Apple's CDN is serving devices right now
curl -sS https://app-site-association.cdn-apple.com/a/v1/example.com

# macOS: force a fetch and print the reason it failed
swcutil dl -d example.com

An SDK becomes necessary at the next step: deferred deep linking, install attribution and campaign analytics all need a pre-install click matched to a post-install open, which the platforms do not do for you.

Where it breaks

Deep linking fails silently by design — a link that cannot be resolved opens the web page instead, with no error anywhere. These are the causes, in the order they actually occur, each with the page that covers it.

The most common failures and where each is diagnosed.
Symptom	Usual cause	Page
Link opens the browser on both platforms	Association file unreachable or behind a redirect	deep-link-opens-browser-instead-of-app
Android links open Chrome	Verification failed — usually the wrong signing fingerprint	why-are-android-app-links-not-working
iOS links open Safari	Missing entitlement, or a wrong App ID Prefix	universal-links-not-opening-app
Worked yesterday, not today	A per-domain "Open in Safari" preference, or a deploy that dropped `/.well-known/`	universal-links-stopped-working
Works everywhere except social apps	In-app browsers intercepting the URL	deep-links-in-in-app-browsers
New installs land on the home screen	No deferred mechanism, or the referrer was lost	deferred-deep-link-not-working

Check the file the way a machine does

Both platforms fetch the association file with no redirects, no cookies and a strict content type, while a browser follows redirects and shows you the file happily. A setup that looks correct in a browser and fails on device is almost always a redirect or a Content-Type — start with curl -sSIL before anything else.

Deep link debugger

Enter your domain and it fetches both association files the way iOS and Android do — following redirects, checking content type, and validating structure, identifiers and fingerprints — then reports exactly which step is failing on each platform.

Open the deep link debugger →

Frequently asked questions

What is a deep link?: A deep link is a URL that opens a specific screen inside a mobile app rather than the app's home screen. Tapping a deep link to a product, profile, or article takes the user straight to that item, the same way a web URL points at a specific page rather than a site's front page.
What is the difference between a deep link and a universal link?: Deep linking is the general concept; universal links are Apple's implementation of it. An iOS universal link is a standard https:// URL that opens your app when installed and falls back to your website when not, verified through an apple-app-site-association file hosted on your domain. Android's equivalent is App Links, verified with an assetlinks.json file.
What is the difference between deep linking and deferred deep linking?: A standard deep link only works if the app is already installed — if it isn't, the link falls back to the web or an app store page and the original destination is lost. Deferred deep linking preserves that destination across the install, so a new user who installs the app lands on the intended screen the first time they open it.
Do deep links work if the app is not installed?: A plain deep link does not. It will fall back to your website or the app store, and the specific destination is discarded. To route a brand-new user to the right screen after they install, you need deferred deep linking, which stores the intended destination and delivers it on first app open.
Why do my deep links open the browser instead of the app?: The most common causes are a missing or malformed apple-app-site-association or assetlinks.json file, the file being served with the wrong content type or behind a redirect, a mismatched team ID, bundle ID, or SHA-256 fingerprint, or Apple's CDN still serving a cached copy of an older file. A deep link debugger will identify which of these is failing.
Do I need an SDK to use deep links?: Not for basic routing — iOS and Android can handle universal links and app links natively once the association files are in place. An SDK becomes necessary for deferred deep linking, install attribution, and campaign analytics, because those require matching a pre-install click to a post-install app open.

Related terms

Universal Link — A Universal Link is a standard HTTPS URL that opens an iOS app directly when that app is installed and the domain has authorised it, and loads the equivalent web page when it is not.
Android App Link — An Android App Link is an HTTPS URL that opens an Android app directly, without a chooser dialog, because the system has verified through a file on the domain that the app is authorised to handle it.
Custom URI Scheme — A custom URI scheme is a non-standard URL protocol, such as myapp://, that an app registers with the operating system so that URLs beginning with it open that app.
Link Fallback Chain — A link fallback chain is the ordered set of destinations a single link resolves to — the app, the app store, or a web page — depending on the user's platform and whether the app is installed.
Deep link opens the browser instead of the app — A deep link opens the browser instead of the app when the operating system has not accepted the app as a verified handler for that URL, or when the tap occurred in a context that never offers the app the chance to handle it.