Free Tool
4.9/5

Free In-App Browser Detector

Am I in an in-app browser? Find out instantly whether this page opened in Instagram, Facebook, TikTok, or another in-app browser, or paste any user agent to decode it. Get the verdict plus honest escape steps.

Useful for support teams: when a user reports a broken link, ask for the string on whatismybrowser.com or from your logs, paste it here, and see exactly which in-app browser they were stuck in.

Sharing links into Instagram and TikTok?

Create Flyn short links that count every click for free, with device, country, and referrer breakdowns on Pro. Deep links on Pro detect in-app browsers and show the visitor that app's exact way out.

Shorten for free

How to Detect an In-App Browser in 3 Steps

Step 1: Open the page or paste a user agent, In-App Browser Detector screenshot
1

Open the page or paste a user agent

Visit this page from the app you want to test (paste the link into a DM to yourself, then tap it), or paste a user-reported user agent string into the analyzer for a support workflow.

Step 2: Read the verdict, In-App Browser Detector screenshot
2

Read the verdict

The detector names the exact in-app browser (Instagram, Facebook, Messenger, TikTok, Snapchat, Pinterest, LINE, LinkedIn), catches generic Android WebViews and iOS embedded views, or confirms a regular browser like Safari or Chrome.

Step 3: Follow the escape steps, In-App Browser Detector screenshot
3

Follow the escape steps

When an in-app browser is detected, the tool shows that app's exact menu path to reopen the page in Safari or Chrome, where app links, OAuth logins, and downloads work again.

What Is an In-App Browser?

An in-app browser is a web view embedded inside a mobile app. When you tap a link in Instagram, Facebook, TikTok, or Snapchat, the page does not open in Safari or Chrome: it opens inside the app, in a rendering component the app fully controls (WKWebView on iOS, WebView or a Custom Tab on Android). It looks close enough to a real browser that most people never notice, right up until something they need, an app link, a login, a download, silently fails.

The differences are structural, not cosmetic. An in-app browser has its own cookie jar, so you are logged out of everything. It has no extensions, no password manager integration on many platforms, and the host app decides which web APIs the page may use. Meta's iOS in-app browser goes furthest: it blocks JavaScript from launching other apps at all, which is why so many links shared on Instagram appear broken when the destination expects to open a native app.

Why Platforms Keep You Inside Their Browser

The first reason is engagement. Every second you spend in Safari is a second you are not scrolling the feed, and a user who leaves the app may not come back this session. The in-app browser keeps the feed one swipe away, which measurably protects session length, the metric social platforms optimize hardest.

The second reason is data and ad attribution. Inside its own browser, the platform can observe how you interact with the pages its ads and links send you to, keeping its conversion loop intact without depending on another browser's privacy rules. None of this is accidental: the in-app browser is a product decision that trades your convenience for the platform's metrics, which is exactly why the escape hatch is always a small menu and never a big button.

What Breaks Inside an In-App Browser

The five failures behind most "your link is broken" reports, and what the user actually experiences.

What breaksWhy it breaksWhat the user sees
App links (deep links)The WebView blocks JavaScript from launching other apps; on iOS, Meta blocks even tap-triggered scheme handoffs in many cases.Tapping "Open in Spotify" or a YouTube link does nothing, or the page just sits on a spinner.
OAuth loginsGoogle returns a disallowed_useragent error for embedded web views because the host app could read the login form."Sign in with Google" shows error 403: disallowed_useragent; other providers fail silently.
File downloadsIn-app browsers have no download manager and no access to the system one, especially on iOS.PDFs, images, and APK files fail without any error message.
Referrer headersMany WebViews strip or rewrite the Referer header, and traffic exits the app without normal navigation context.Analytics report the visit as "direct" traffic, so the real source app gets no credit.
Cookies and sessionsEach app's WebView has its own cookie jar, fully separate from Safari or Chrome.Users are mysteriously logged out of sites they use every day, and carts or preferences are empty.

How to Escape Each App's In-App Browser

Every major app hides an exit. Here is where each one keeps it.

Instagram

Tap the three dots at the top right, then choose "Open in external browser".

Facebook

Tap the three dots menu, then choose "Open in Safari" (iOS) or "Open in browser" (Android).

Messenger

Tap the three dots menu, then choose "Open in Safari" (iOS) or "Open in browser" (Android).

TikTok

Tap the three dots menu, then choose "Open in browser".

Snapchat

Tap the three dots menu, then choose "Open in Safari" (iOS) or your default browser on Android.

LinkedIn

Tap the three dots menu, then choose "Open in Safari" (iOS) or "Open in browser" (Android).

Pinterest

Look for the menu or export icon in the corner of the browser view, then choose the open-in-browser option, or copy the link and paste it into your browser.

LINE

Tap the menu in the corner of the browser view, then choose "Open in Safari" (iOS) or "Open in other app" (Android).

Any other app

Find the menu (usually three dots), pick "Open in browser" or "Open in Safari". No menu? Copy the link address and paste it into your real browser.

Why "Bypass the In-App Browser" Claims Fail

Search for this problem and you will find services promising to break your links out of Instagram automatically. Here is the honest version: Meta's iOS in-app browser blocks automatic app launches, and no service reliably bypasses it. Every trick so far has followed the same life cycle. The x-safari-https scheme forced a handoff to Safari until Instagram blocked it. Redirect chains through ftp or blob URLs, intent workarounds, and dialer-scheme hacks each worked for weeks or months, spread across marketing forums, and were patched. The platform controls the WebView; whoever controls the WebView wins the cat and mouse game.

What actually works is detection plus a guided escape. Detect the in-app browser server-side (the way this tool does client-side), then show the visitor a purpose-built page: one clear tap to attempt the app on platforms where that still works (Android intent URLs usually launch it), and honest instructions for the three dots menu where it does not. That converts a silent failure into a two-second detour. It is exactly what Flyn's deep links do on Pro, and it outperforms any "bypass" because it never breaks when the platforms patch the next trick. The long version, including what breaks inside the in-app browser and how to read the user agent yourself, is in Instagram in-app browser: why links break and the fix.

Detect Here, Fix It on Your Links with Flyn

The detector diagnoses one visit. Flyn short links apply the fix to every click you ever share into a social app.

Deep links with escape pages

On Pro, deep-link-enabled links check the user agent on each mobile click: Android usually gets the app launch, iOS inside a social browser gets a guided escape page instead of a blank screen.

Click analytics

Count every click free. On Pro, see device, country, and referrer breakdowns to spot how much of your traffic arrives through in-app browsers.

Smart routing

Route clicks by device or country on Pro, so iOS, Android, and desktop visitors each land where the link actually works for them.

Sub-50ms redirects

Detection happens during the redirect itself, so an in-app visitor gets the escape page instead of a dead end, and every other click redirects as usual.

Deep links and smart routing are Pro features. See how Flyn deep links work

Frequently Asked Questions

What is an in-app browser?
An in-app browser is a stripped-down web view embedded inside a mobile app like Instagram, Facebook, or TikTok. When you tap a link in those apps, the page opens inside the app itself instead of in Safari or Chrome. It looks like a browser, but it runs with the host app's restrictions: no extensions, separate cookies, and tight limits on what the page is allowed to do.
Why do links open blank or broken in Instagram?
Instagram's in-app browser, especially on iOS, blocks JavaScript from launching other apps and from starting downloads. A link that tries to open Spotify, a banking app, or an APK file often just does nothing, which reads as a blank or broken page. The link itself is usually fine: the same URL works the moment it is opened in Safari or Chrome.
How do I open a link in Safari from Instagram?
Tap the three dots at the top right of Instagram's in-app browser, then choose "Open in external browser". The page reloads in Safari (or your default browser on Android) where app links, logins, and downloads work normally. This menu is the only reliable exit: Instagram gives web pages no way to trigger it automatically.
How do I escape the Facebook or Messenger in-app browser?
In both Facebook and Messenger, tap the three dots menu, then choose "Open in Safari" on iOS or "Open in browser" on Android. Snapchat and LinkedIn use the same three dots pattern. Once the page is in your real browser, everything the in-app browser blocked starts working again.
How do I open links in my real browser from TikTok?
Tap the three dots menu inside TikTok's in-app browser and choose "Open in browser". TikTok's WebView is one of the more restrictive ones, so links to other apps and OAuth logins frequently fail until you do this. If the menu is missing on an older version, copy the link address and paste it into your browser manually.
Why do apps force links through their own browsers?
Two reasons: engagement and data. Keeping you inside the app means you return to the feed with one swipe instead of getting lost in Safari, which protects session time. The embedded browser also lets the platform observe activity on pages you visit, inject scripts, and keep its ad attribution loop intact. It is a deliberate product decision, not a bug.
Does the x-safari-https:// trick still work to escape Instagram?
No, not reliably. The x-safari-https scheme briefly forced iOS to hand a URL to Safari, and Instagram blocked it once it spread. Every silent bypass so far has followed the same arc: discovered, shared, patched. It is a cat and mouse game the platforms always win, which is why no service can honestly promise an automatic escape from Meta's iOS in-app browser.
What breaks inside in-app browsers?
Four things break most often: app links (a Spotify or YouTube link cannot launch the native app), OAuth logins (Google blocks sign-in from embedded web views entirely), file downloads (PDFs and APKs silently fail, especially on iOS), and referrer headers (analytics see the traffic as "direct" instead of crediting the real source). Cookies are also sandboxed per app, so users appear logged out of sites they use daily.
Can I detect an in-app browser from the user agent alone?
Usually, yes. Named apps leave tokens in the UA string: "Instagram", "FBAN" or "FB_IAB" for Facebook, "musical_ly" or "Bytedance" for TikTok, "Snapchat", "LinkedInApp", and so on. Generic embeds are caught by two fallbacks: Android WebViews carry a "; wv)" marker, and an iPhone UA missing the "Safari/" token is an embedded WKWebView. A small minority of apps spoof a clean UA, so no detector is 100 percent.
Is this a WebView detector or a user agent checker?
Both, in one page. As a WebView detector it reads your live visit and names the app whose embedded browser you are in, and it still flags the unnamed ones: an Android WebView carrying the "; wv)" marker, or an iPhone UA missing the "Safari/" token, which means an embedded WKWebView. As a user agent checker it decodes any UA string you paste, so you can test a string pulled from a support ticket or a server log without owning that phone. Either way the parsing happens in your browser and nothing is uploaded.
Why does Google block logins inside in-app browsers?
Google has refused OAuth sign-in from embedded web views since 2016, returning a "disallowed_useragent" error, and has tightened enforcement since. The reason is security: the host app fully controls an embedded browser, so it could read keystrokes, including passwords, on the login page. Many other providers apply similar policies, which is why "Sign in with Google" buttons dead-end inside Instagram.
How do Flyn deep links handle in-app browsers?
On links with deep links enabled (a Pro feature) whose destination is one of the 16 supported platforms, Flyn checks the user agent on each mobile click. On Android, intent URLs usually launch the app and fall back to the web page when they do not. On iOS inside a social in-app browser, where automatic launches are blocked, Flyn serves a guided escape page instead of a blank screen: one clear tap to try the app, plus that app's exact way out to Safari. See the deep links feature page for details.
Is this in-app browser detector free?
Yes. The detector is completely free, needs no sign-up, and the analysis runs entirely in your browser: the user agent you paste is never uploaded or stored. Flyn makes money from Pro features like deep links, smart routing, and analytics breakdowns on short links, not from this tool.

Stop losing clicks to in-app browsers

Diagnose the problem here, then share Flyn short links that handle it for you: free click counts and QR codes, with deep links, smart routing, and analytics breakdowns on Pro.