You tap a link in an Instagram bio and it opens — but not in Safari or Chrome. It opens in a stripped-down browser inside Instagram, with the app’s own header bar at the top. Your passwords do not autofill. Your extensions are gone. And links that should open another app just… don’t.
That is an in-app browser, also called a webview. Most large social apps use one.
Why apps do this
Keeping you inside the app is the point. When a link opens your real browser, the app loses you — you have left, and the session ends. An embedded webview keeps the visit inside the app, where the app controls the back button, keeps its own header on screen, and can measure what you did.
There are secondary reasons that are less cynical: the transition is faster than a cold browser launch, and the app can render a consistent chrome around untrusted content. But retention is the main driver.
What actually breaks
The webview is a real browser engine, so most pages render fine. What breaks is everything that depends on being your browser:
- Your login sessions do not carry over. The webview usually has its own cookie jar, so you appear logged out of sites you are signed into.
- Password managers and autofill often do not work, or work inconsistently.
- Extensions do not exist. No ad blocker, no password manager extension.
- Deep links do not hand off. This is the big one. A link that would normally open the YouTube or Spotify app stays in the webview, showing the website instead.
- Some payment and OAuth flows fail outright, because providers deliberately refuse to run sign-in inside an embedded browser. Google has blocked OAuth in webviews for years.
Why deep links fail specifically
When you tap a link in your real browser, the operating system inspects it first and checks whether an installed app has claimed that destination. If one has, the OS hands the link to that app instead of rendering it as a web page. That check is what makes a link open an app at all.
Inside a webview, that check usually never happens. The host app is rendering the page itself and does not pass the URL back to the operating system for routing. So the link resolves to its web fallback — the website — and the native app never opens.
This is not something a link can fix. No link generator, including this one, can force an app’s embedded browser to hand off to another app. Anyone claiming otherwise is describing something the platforms do not permit.
How to get out of an in-app browser
On both platforms the reliable move is the same: use the share or overflow menu.
- iOS: tap the “…” or share icon, then Open in Safari (or Chrome, if it is your default). Some apps put this in the bottom bar.
- Android: tap the three-dot menu, then Open in browser or Open in Chrome.
Once the page is in your real browser, tapping the same link routes normally and the app opens.
You can also long-press a link before tapping it and choose to open it in your browser directly, which skips the webview entirely.
What this means if you are sharing links
If you put a link in an Instagram bio, a TikTok profile or a Facebook post, assume a large share of taps will land in a webview. That is outside your control. What you can control:
- Always keep a working web fallback. A link that only works when the app opens will fail for a lot of people. Every link toThe.App generates keeps the website as the fallback for exactly this reason.
- Do not put sign-in or checkout behind the first tap. Those are the flows most likely to break in a webview.
- Tell people to open in their browser when the destination genuinely needs the app. A short “open in your browser for the best experience” note costs nothing.
The short version
In-app browsers exist to keep you in the app. They break deep links because they do not hand URLs back to the operating system for routing. You escape them through the share menu; as a publisher, you plan around them by never depending on the app actually opening.
If you want a link that offers the app first and falls back to the web cleanly, the free deep link generator does that, and each per-app guide documents exactly where the fallback kicks in.