← all posts
The Zippy Team

Why your links die in the in-app browser (and how to escape it)

Every social app opens your links in a crippled internal webview — no logins, no cookies, broken pixels. Here's what's actually happening to your clicks, and how native-app deeplinks get them out.

in-app browserdeeplinksconversion
Zippy the lightning-bolt mascot springing out of a phone's cramped in-app browser window

You post a link on Instagram. Someone taps it. Instagram does NOT open their browser — it opens a little browser inside Instagram. Same on TikTok, LinkedIn, X, Reddit, WhatsApp. That little browser is called an in-app webview, and it is where your clicks go to die.

Zippy, the lightning-bolt mascot

Zippy: the in-app browser is a phone booth pretending to be a browser. logged out of everything, half the buttons broken. my whole job is springing you out of it.

We built Zippy because we kept watching the same thing happen to affiliate marketers, creators, and social operators: great content, real taps, and conversion numbers that made no sense. The missing clicks weren't missing. They were dying in the webview.

What an in-app webview actually is

When an app "opens a link", it has two options: hand the URL to the phone's real browser (Safari, Chrome), or render the page inside its own embedded browser component (WKWebView on iOS, Custom Tabs / WebView on Android). Social apps almost always choose the second — it keeps you inside their app, watching their ads, on their clock.

The embedded browser looks like a browser. It is not your user's browser:

  • Separate cookie jar. The webview shares nothing with Safari or Chrome. Your follower has been logged into YouTube in their real browser for six years — in the webview, they're a stranger.
  • Separate storage. localStorage, sessionStorage, IndexedDB — all sandboxed, all empty, frequently wiped.
  • Neutered features. Payment sheets, password managers, OAuth popups, file pickers, sometimes entire JS APIs — degraded or gone.

The three ways this eats your money

1. The login wall

"Follow me on YouTube" → tap → YouTube.com in the webview → "Sign in to continue." Nobody signs in. They were already signed in — in the app you didn't open. The subscribe never happens, and it doesn't show up in any dashboard as a failure. It just quietly doesn't happen.

2. The pixel that never fires

Attribution runs on cookies and storage. In the webview your Meta pixel, your affiliate network's click ID, your UTM-based session — all of it lands in a sandbox that gets wiped. The click happened. Maybe the sale happened later, in the real browser, uncredited. Your dashboard says the campaign failed. You kill a campaign that was working.

3. The checkout that chokes

Apple Pay sheets that don't open, password managers that don't autofill, 3DS redirects that dead-end. Every extra step in a crippled browser sheds buyers who were already past the hard part — they tapped.

Zippy, the lightning-bolt mascot

Zippy: they wanted to pay you. the webview ate the checkout. that's not a "them" problem, that's a plumbing problem.

The escape hatch: deeplinks

Every major platform registers a URL scheme or App Link that opens content directly in its installed native app: vnd.youtube://, instagram://, linkedin://, Android intent URLs, iOS Universal Links. Open a link that way and the user lands in the real app — logged in, payment methods attached, everything working.

The catch: doing this right is genuinely annoying.

  • Every platform has its own scheme, and they change without notice.
  • iOS and Android need different escapes for the same destination.
  • Some webviews block schemes unless you bounce through a redirect first.
  • You need a web fallback when the app isn't installed — without breaking the case when it is.

That's a routing table you have to maintain, not a snippet you paste once. Which is the actual product: a Zippy link detects the platform the tap came from and the platform it points at, then springs the real native app — LinkedIn, Instagram, WhatsApp, Reddit, Product Hunt, YouTube, TikTok, X — with clean web fallbacks when there's no app to open. We maintain the routing table so you don't learn about a scheme change from your conversion graph.

Check it yourself

Don't take any of this on faith. Two-minute test:

  1. Post a link to your own site in an Instagram story or a TikTok bio.
  2. Tap it from the app, and look at the top of the screen — that's the webview chrome, not your browser.
  3. Visit any site you're normally logged into. Stranger.

Then try the same tap through a Zippy link and watch the real app open instead.

Zippy, the lightning-bolt mascot

Zippy: one tap, real app, already logged in. no phone booth. this is the whole trick, and honestly it slaps.

FAQ

What is an in-app browser (webview)?

An in-app browser is a stripped-down browser that a social app opens inside itself instead of handing the link to Safari or Chrome. On iOS it's usually WKWebView; on Android it's Custom Tabs or a WebView. It keeps users inside the app, but it has its own empty cookie jar and storage, so visitors arrive logged out with broken pixels and flaky checkouts.

Why do my links break inside Instagram and TikTok?

Because the tap opens your page in the app's in-app webview, not the user's real browser. That webview shares no cookies, logins, or saved payment methods with Safari or Chrome, so "sign in to continue" walls appear, attribution pixels land in a sandbox that gets wiped, and payment sheets fail. The click happened; it just died in a browser that wasn't your user's.

What is a deeplink, and how does it fix this?

A deeplink is a URL that opens content directly in an installed native app — instagram://, vnd.youtube://, Android intents, iOS Universal Links — instead of a webview. Opening a link that way lands the user in the real app, logged in with everything working. The hard part is that every platform has its own scheme and they change without notice, which is the routing table Zippy maintains.

How do I get my links out of the in-app browser?

Route them through a link that detects the webview and springs the real native app. A Zippy link reads which platform the tap came from and which app it points at, then opens that app directly — with a clean web fallback when the app isn't installed. You post one link; Zippy handles the per-platform escape.

The in-app browser isn't going away — it's how the platforms want it. But your links don't have to die there.