Tap a link inside Instagram, TikTok, Facebook, or LinkedIn and a page opens without you ever leaving the app. No browser icon appears in your app switcher. No tab opens in Safari or Chrome. That page is running inside the app's own in-app browser, and it behaves differently from your real browser in ways that cause a specific, recurring set of problems.
How an in-app browser works
Every major mobile OS gives app developers a component for rendering web content without leaving the app: WKWebView on iOS, WebView or Chrome Custom Tabs on Android. An in-app browser is that component, wrapped in the host app's own toolbar and navigation. It reads HTML, runs JavaScript, and renders CSS the same way Safari or Chrome does, because under the hood it mostly is the same rendering engine. What differs is everything around it. The cookie jar it uses, whether it remembers your saved passwords, and who else gets to run code on the page besides the website itself.
That last point is the one most explanations skip. A regular browser only runs the JavaScript a website ships. An in-app browser can also inject its own code into every page it loads, layered on top of the site's own code, before the page is ever handed to the visitor.
In-app browser vs your phone's real browser
| Safari or Chrome (your default browser) | Instagram, TikTok, or Facebook's in-app browser | |
|---|---|---|
| Login session storage | Persists across sites you're logged into | Usually a fresh, separate cookie jar (iOS WKWebView); Android's Custom Tabs sometimes shares Chrome's session instead, depending on the app |
| Saved passwords and autofill | Available | Not available |
| Extensions and ad blockers | Available | None |
| History and bookmarks | Saved | Not saved |
| Who can run code on the page | Only the website | The website, plus whatever the host app injects |
| Getting back to it later | Any time, it's a normal tab | Usually gone once you close it, unless you find the escape menu |
The Android row is the one worth sitting with. Chrome Custom Tabs, which some Android apps use, can actually share Chrome's real cookies and saved logins, unlike Apple's WKWebView, which almost never does. The same social app can behave differently on the two operating systems for that reason alone, which is part of why a login problem reported by an iPhone user and an Android user for the same in-app browser can have different root causes.
The Instagram in-app browser, specifically
Instagram's in-app browser is the one most people run into daily, since it opens for nearly every outbound link tapped from a post, story, bio, or DM. On iOS it uses a WKWebView with its own separate cookie storage, so a login session in Safari does not carry over, and a login completed inside Instagram's browser does not carry back out either. Independent research published in 2022 by developer Felix Krause found that Instagram's and TikTok's in-app browsers injected extra JavaScript into every third-party page rendered inside them, code capable of tracking taps and monitoring input typed into forms on pages that had nothing to do with either platform. Meta said the code existed to honor people's tracking preferences and disputed that it was used to log keystrokes, but did not dispute that the code itself was present. Whatever the intent behind it, it is a real example of the core difference between the two kinds of browser: opening a link inside an app gives that app's own code a seat at the table on every page you visit next, not just the app's own pages.
Instagram does report tap counts on links placed in a professional account's bio, visible in that account's own insights, which is a separate and far more limited kind of visibility than the in-app browser question above.
Common in-app browser problems
A handful of things break with real consistency. Logins don't stick. A session started inside the in-app browser is usually gone the moment you close the app and open the site again in Safari or Chrome. Saved passwords and autofill don't work either, because password managers are tied to the real browser, not the WebView an app wraps around a page, and that same gap is what breaks checkout flows relying on saved card details or a one-tap fill. Extensions and ad blockers don't run at all, since none of that tooling applies inside a WebView. And pop-ups, redirects, and some deep links get blocked outright: in-app browsers frequently suppress the exact handoff a page relies on to send a visitor into a native app, covered in what a deep link is and in why links open in the wrong browser in the first place.
How to open a link in your external browser instead
Most platforms that use an in-app browser put an escape hatch somewhere in the toolbar, usually a "..." or share icon in a top or bottom corner, with an option along the lines of "open in browser" or "open in Safari." It is rarely the default action. It is easy to miss on a first look. Instagram is the one platform that also offers a persistent, app-wide toggle for it, under Settings and privacy, in Website permissions, where "open links in external browser" can be switched on so every future link skips the in-app browser entirely.
Why this matters for tracking a link's clicks
An in-app browser is not just a UX annoyance. It changes what a link's own tracking sees, because it is a separate browser instance with its own cookie jar on every click, for every visitor who has not gone looking for the toggle above. That is one reason cookie-based click tracking alone undercounts returning visitors coming from social apps, and part of why Raydar logs a click server-side, at the point its redirect is served, rather than waiting on a script that has to survive inside whatever browser happened to open it. A link that also needs to hand a visitor off to a native app runs into the same problem from a different angle, which is where deep links and in-app-browser escape prompts come in.