ChatGPT Mobile Started Opening Links Inside the App - And It’s Part of a Bigger “Don’t Leave” Trend
Over the last months, a lot of people noticed something small but important in the ChatGPT mobile app: when you tap a link, it often opens inside ChatGPT instead of jumping to your default mobile browser (Safari/Chrome).
You can see the frustration in public threads asking OpenAI to add a toggle to disable the in-app browser on iOS. (OpenAI Developer Community)
This is not just a ChatGPT thing. It fits a bigger pattern that’s been building for years: big apps increasingly try to keep you inside the app instead of handing you off to the open web.
Let’s break down what’s happening, why it’s happening, and what it means if you build websites, landing pages, or web apps.
What changed with ChatGPT links on mobile?
On Android, OpenAI’s own help docs still describe links opening via your default browser (for example, setting Chrome as default). (OpenAI Help Center)
But in practice - especially on iOS - many users report the ChatGPT app using an embedded in-app browser flow, with extra taps needed to open in their preferred browser. (OpenAI Developer Community)
So the reality looks like this:
Sometimes ChatGPT opens links externally (system default).
Sometimes it opens links internally (in-app web view).
Users want a simple “Always open externally” toggle.
That inconsistency matters because in-app browsers behave differently than Safari/Chrome.
Why do big apps want links to open inside the app?
Because the moment you leave an app, the app loses:
Time-on-app
Engagement signals (likes, replies, follows, scroll depth)
Ad measurement and attribution
Conversion control (especially if they want checkout and subscriptions to happen in-app)
You can see this mindset openly in product decisions across the industry. For example, X has tested link handling changes designed specifically to keep the post visible while you browse, so you’re less likely to “leave and forget” the app. (The Verge)
This is the same gravity pulling everything toward “the app is the destination” - not a gateway to the web.
Did this “don’t leave the app” trend start with Facebook?
Facebook is not the first app to embed web content, but it’s one of the biggest platforms that normalized it at massive scale.
Here’s the timeline in plain language:
1) Early mobile apps used WebViews a lot
Embedded web views (in-app browsers) have been common for a long time because they’re easy to implement and keep users in one flow.
2) Facebook’s mobile history pushed heavily into webview-based experiences
Facebook famously went through a phase where parts of its mobile experience leaned on a hybrid webview approach, then rebuilt to more native code for performance. (TNW | The heart of tech)
3) Facebook (and others) later doubled down on opening links inside the app
A more modern example: reporting around Facebook on Android describes it opening web links inside the app using Android’s WebView component, rather than the user’s default browser. (The Register)
And the “in-app browser” has become a defined product surface for Meta platforms (Facebook/Instagram). (Facebook)
So if you’re asking “was Facebook the start?” - the most accurate answer is:
No, embedded browsers existed before.
Yes, Facebook helped make it mainstream, and social apps then turned it into a standard playbook.
The hidden downside: in-app browsers can be a worse web
In-app browsers can create real issues for users and site owners:
Login loops and broken SSO flows
Cookie and storage weirdness
Missing extensions (password managers, autofill behaviors, content blockers)
Performance differences (older webview behavior, odd caching)
Less transparency about what’s happening in the browsing context
There’s also ongoing industry discussion about privacy and the ability for apps to observe or even inject behavior into embedded browsing contexts. (Frontend Masters)
What this means for web developers and founders
If a meaningful share of your traffic comes from:
ChatGPT mobile
Instagram / Facebook
X
LinkedIn
Gmail in-app
Slack mobile
…then a chunk of users are not experiencing “real Safari/Chrome.” They’re in a WebView environment.
Practical implications
Analytics attribution can change (referrers, UTM handling, session continuity).
Auth flows (Google/Microsoft login, magic links) can be less reliable.
Payments and embedded checkout flows can behave differently.
Support tickets increase because “it works on my phone browser” but not inside an app browser.
What to do about it (actionable checklist)
1) Test your key flows inside in-app browsers
Test at minimum:
landing page + pricing
sign up + email verification
login + password reset
checkout (Stripe, Shopify, etc.)
2) Make “Open in browser” easy
If your product depends on a stable browser experience, add a visible option:
“Open in Safari/Chrome”
“Copy link”
“Continue in browser for best experience”
3) Harden auth flows
Avoid fragile cross-site cookie assumptions
Be careful with redirect chains
Make magic-link flows resilient to context switching
4) Treat WebViews as a first-class client
If you build serious web apps, it’s worth having a small “in-app browser compatibility” pass in your QA process.
Bigger picture: the web is still the most neutral layer
A great line from the universal links era was basically: “apps don’t agree on standards, so the web remains the most consistent cross-platform solution.” That tension has been around for years. (WIRED)
And now, as AI apps become gateways to content, it’s not surprising they want to own more of the browsing experience too.