In-app browsers
In-app browsers, explained: what they are and what they break
Roughly every link tapped inside TikTok, Instagram or Facebook opens in a webview, not a browser. Here is what that costs you — and why the failures are so hard to see in analytics.
An in-app browser is a web page rendered inside another app. When you tap a link in TikTok, Instagram, Facebook, LinkedIn, Snapchat or Gmail, the app does not hand the URL to Safari or Chrome. It opens a browser-shaped panel of its own and loads the page there.
Technically these are webviews — WKWebView on iOS, WebView or a Custom Tab on Android. They use the same rendering engine as the system browser, which is why pages usually look right. What they do not share is the part that makes a browser useful: your session, your extensions, your payment sheet, your download handling.
Why apps do this at all
The honest answer is retention. Handing a user to Safari is an app switch, and an app switch is a chance to not come back. A webview keeps the user one swipe from the feed. Secondary reasons exist — faster perceived load, a consistent close button, the ability to overlay the app's own UI — but retention is the one that decides it.
This matters for expectations: in-app browsers are not a temporary quirk waiting to be fixed. They are a deliberate product decision by the platforms, and they have become more common, not less.
What actually breaks
The failures cluster into five groups. All of them share a property that makes them expensive: they usually fail quietly.
| What breaks | Why | What the visitor experiences |
|---|---|---|
| Logins and OAuth | The webview has its own cookie storage, isolated from Safari or Chrome | Signed in everywhere else, signed out here. "Continue with Google" loops or dead-ends |
| Password managers | Browser extensions do not run inside a webview | No autofill, so a long password has to be typed by hand on a phone |
| Wallet payments | Apple Pay and Google Pay are frequently unavailable in a webview context | The one-tap payment button is missing; checkout becomes manual card entry |
| Downloads | File handling is limited or absent depending on the host app | A PDF, ticket or invoice tap that does nothing at all |
| Analytics and pixels | Third-party storage restrictions and inconsistent script execution | Nothing — which is the problem. The visit is under-counted or mis-attributed |
How much of your traffic is affected
It depends entirely on where your traffic comes from, and the split is stark. Search and newsletter traffic almost never arrives through a webview. Social traffic almost always does — if someone tapped a link inside TikTok or Instagram, they are in the in-app browser by default.
So the practical question is not "how big is this problem in general" but "what share of my visitors come from a social app". For a creator with a link in their TikTok bio, that share is close to everything. For a B2B site with mostly organic search traffic, it may be a rounding error.
You can check this yourself: most analytics tools expose the user-agent string, and in-app browsers announce themselves in it. Look for Instagram, FBAN/FBAV (Facebook), TikTok, musical_ly, Line, Snapchat or LinkedInApp as substrings. Segmenting conversion rate by that flag is usually the moment the problem stops being abstract.
What you can actually do about it
You cannot stop a platform from using a webview, and you cannot force a link out of one from the outside. What you can do is stop treating in-app traffic like normal traffic.
- 1Detect it. Read the user-agent and know which visitors are in a restricted context before you render anything.
- 2Simplify what you ask of them. If someone is in a webview, a long form with a password field is a bad first request. A single primary action converts far better.
- 3Offer a route out, explicitly. A visitor who is told "this needs your normal browser — here's how" will follow along. One who hits a broken payment sheet will not.
- 4Attempt the supported hand-off. Android's intent URLs work reliably; other paths depend on the platform and the OS version. Try what is supported, never depend on it.
- 5Always keep the copy-link fallback. Copying the URL and pasting it into Safari or Chrome works on every device, every version, every time.
That last pair is the whole design principle: attempt the automatic route, but build the flow so it still works perfectly when the attempt fails. Anything that only works when the platform cooperates will break the week the platform changes.
If you want the platform-specific detail, we broke down TikTok's in-app browser and Instagram's in-app browser separately — they behave differently enough to be worth reading apart.
Frequently asked questions
Is an in-app browser the same as a webview?
Effectively yes. "Webview" is the technical component an app embeds to render web content; "in-app browser" is the user-facing browser-like panel built on top of it, usually with an address display, a close button and a share menu.
Do in-app browsers see my browsing data?
The host app controls the webview, so it can in principle observe navigation within it and inject its own JavaScript. What each app actually does varies and is a matter for their privacy policies. Traffic to your site over HTTPS is still encrypted in transit.
Can I block in-app browsers from opening my site?
You should not. Blocking a webview visitor means blocking a real person who wanted to visit you. Detecting the context and guiding them to a browser that works converts far better than refusing to render.
Which apps use in-app browsers?
Most social and messaging apps: TikTok, Instagram, Facebook, Messenger, Snapchat, LinkedIn, Pinterest, Reddit, X, Line, WeChat and many email clients. Behaviour and available escape hatches differ per app and per OS version.