In-App Browser Consent: When Visitors Arrive via WebView

The traffic you forget to test

When someone taps your link inside Instagram, Facebook, TikTok, or LinkedIn, the page usually doesn't open in Safari or Chrome. It opens in an in-app browser, an embedded WebView the app controls. For a lot of consumer brands this is a large share of mobile referral traffic, and it's the version of your site most people never QA. Your consent banner still has to render there, work with touch, and behave under storage rules that are different from a normal browser.

What's technically different in a WebView

Two things change the moment your page loads inside an iOS WebView. First, WKWebView has had Intelligent Tracking Prevention enabled by default since iOS 14, so third-party cookies are blocked by default in these embedded browsers. Tags that depend on third-party cookies quietly fail. Second, storage in the WebView can be isolated to that app's instance and may not persist to the user's own Safari. So a consent choice a visitor makes inside the Instagram browser doesn't necessarily carry over to a later visit in Safari, and vice versa. Cookie behavior across WebViews is inconsistent enough that developers track it on references like caniwebview.

The practical effect: expect re-prompting. A returning visitor who consented in Safari can show up in the TikTok browser as a fresh, unconsented user because the storage is a different jar. That's not a bug in your banner. It's the isolation doing its job.

The host app can see more than you'd guess

In-app browsers aren't neutral windows. Security researcher Felix Krause documented in 2022 that the Instagram, Facebook, and TikTok in-app browsers inject JavaScript into the pages they load and can observe taps, form inputs, and scrolling on any site opened inside them. Apple's response was App-Bound Domains: a site or app can add the WKAppBoundDomains key so a WebView denies JavaScript injection, cookie manipulation, and message-handler access unless the domain is on the allowed list.

You can't stop another company's app from wrapping your page in its browser, but this is context your privacy notice and your threat model should acknowledge. When a visitor is inside a social app's browser, a third party may be observing the session in ways your own consent banner has no control over.

Android behaves differently from iOS

The Android side splits in two. Apps that use Chrome Custom Tabs hand the page to a tab that shares cookies and storage with the user's Chrome, so consent can persist and the experience is close to a normal browser. Apps that use a raw Android WebView get isolated, app-scoped storage much like iOS, so consent doesn't carry over. You can't tell from your server which one a given app chose, so treat in-app traffic as a spectrum: some of it persists, much of it doesn't.

This has a measurement consequence worth naming. Consent rates and returning-visitor counts look worse for in-app traffic because a chunk of it is structurally single-session. When you benchmark consent performance, segment in-app browser sessions out rather than letting them drag your averages down and send you chasing a banner problem that's really a storage-isolation artifact. Our consent rate benchmarks read more honestly once you do.

Consent still applies, and gets harder

None of this exempts you. Article 5(3) of the ePrivacy Directive applies to storage inside a WebView exactly as it does in a full browser, so your banner has to be there and has to gate non-essential tags. What the WebView adds is friction: third-party-cookie blocking breaks tag-based attribution, isolated storage means consent doesn't persist across contexts, and some measurement tools silently return nothing. Don't paper over the re-prompt or try to force persistence you can't get; design for a world where a meaningful chunk of visitors are single-session and cookie-limited.

Don't rely on "open in your browser"

Some sites detect an in-app browser from the user-agent string and nudge the visitor to reopen the page in Safari or Chrome, usually to fix a broken login or payment flow. That's a fine fallback, but it isn't a consent strategy. Most people won't take the extra step, and until they do they're on your page inside the WebView, where the banner still has to render and gate tags correctly. Treat the reopen prompt as a convenience for flows that genuinely break, not as a way to dodge showing a working consent experience in the embedded browser. And test the reopen path itself, because a banner that only behaves after a context switch fails the majority who never switch.

What to actually do

1. Test inside the real in-app browsers. Open your own link from Instagram, TikTok, and Facebook on a physical phone and watch the banner render and function.
2. Keep the banner usable at small size and with the app's own chrome overlapping the viewport; the sizing and reject-button placement in our mobile banner optimization guide matter more here, not less.
3. Lean on first-party, consent-gated measurement that doesn't depend on third-party cookies, since those are blocked by default. Our guide on first-party versus third-party cookies explains the split.
4. Don't assume App Tracking Transparency covers this. ATT governs an app's access to the device IDFA; it says nothing about the cookie consent your web content owes. That's a separate obligation, covered in our mobile app consent guide.

CookieBeam renders in an in-app WebView like it does in any browser, so the banner shows up where this traffic actually lands, and you can point its scanner at the same URLs to confirm what loads before consent. The harder truth is architectural: build your measurement to survive isolated storage and blocked third-party cookies, because a growing share of real visits happen in exactly that environment.