Designing for the in-app browser.

A restaurant owner replied to our Instagram message to say the link we'd sent was broken. We tested the URL immediately. It worked perfectly in Chrome, in Safari, in Firefox — on iOS, on Android, on desktop. Every browser we owned opened it without a hiccup.

The problem was the one browser we hadn't been thinking about. Instagram had opened the link inside its own in-app browser, silently mangled it on the way, and dropped him somewhere that wasn't the page we'd built. He saw a broken experience and reasonably concluded the website was broken. It wasn't. But the damage was done — that single moment cost us a week of momentum, and a conversation we'd spent real care starting nearly didn't survive it.

01 · The Hidden WebThere is a second web, and you don't control it.

When someone taps a link inside Instagram, Facebook, TikTok or LinkedIn, they usually don't leave the app. The link opens in a webview — a stripped-down browser embedded in the social app itself. To the user it looks like a browser. Technically, it is one. But it is not the browser their phone ships with, and it does not behave like it.

Each platform builds its own. Each one strips and rewrites things on the way through. Certain HTTP headers get dropped. Third-party cookies are frequently blocked, which quietly breaks logins, carts and anything that relies on a session it didn't set itself. Some JavaScript APIs that exist in a real browser simply aren't there — share sheets, certain storage calls, payment and clipboard hooks that your code assumes are safe to call.

Then there's what gets misrendered rather than removed. Custom fonts above roughly 200KB can fail to load, so your carefully chosen typeface falls back to a system one and the whole page suddenly looks like a draft. Video codecs are a lottery — a hero clip that plays everywhere else can refuse to start. Dynamic favicons, service workers, and anything clever you did with the URL can all behave differently or not at all.

Worse, these failures are inconsistent between platforms and between app versions. A link that survives the TikTok webview chokes in the LinkedIn one. A page that rendered fine last month breaks after the app updates its embedded engine — and you never get told. There is no error console you can read, no support ticket you can file, no way to even reproduce the bug unless you happen to own the exact device, app version, and network conditions the user had.

The cruel part is the attribution. The user never thinks the app's browser mishandled this. They think the website is broken. And in a very real sense the website is fine — it was the webview that broke it, somewhere the owner of the site can't see and can't fully control. This is the same trust problem we wrote about in why most chatbots feel like a wall: the failure lands on the business even when the business did everything right.

02 · The TestWhat to actually check in 2026.

The fix isn't glamorous. It's a discipline, and most of it is about testing the thing the way it will actually be used rather than the way it's convenient to build it.

Test the published URL where it will live

Always open your real, published link by sharing it through the social network you'll actually share it on — paste it into an Instagram DM to yourself and tap it from inside the app. Testing in desktop Chrome proves nothing about how it behaves in Instagram's webview. The only honest test reproduces the real path.

Keep the link clean

Avoid URL wrappers, redirect chains and decorative query strings. Every redirect is another chance for a webview to lose the trail, and long tracking-laden URLs are exactly what some in-app browsers trip over. A short, direct, https:// link survives more often than a clever one.

Make the first screen ridiculously light

Keep above-the-fold weight punishingly small — under about 200KB if you can. Webviews on a cold connection inside an app are the worst-case loading environment you have, and the heavier the first paint, the more chances something fails. This is also why we keep our own maintenance and performance work boring on purpose: lightness is a feature, not a leftover.

Prefer plain links over JS routing

A plain <a href="https://…"> beats JavaScript-routed navigation every time inside a webview. Client-side routers depend on history and storage APIs that in-app browsers sometimes restrict, and when they fail they fail invisibly. Real anchors don't.

Encode video for the worst viewer

For hero video, use H.264 with progressive loading. AV1 and HEVC are more efficient and look gorgeous in a modern browser, but webviews refuse them inconsistently — and an inconsistent refusal is worse than a predictable limitation, because you can't test your way out of it reliably.

Warn at the top of anything interactive

For interactive plans, proposals or configurators, print a visible note at the very top: best opened on desktop — copy this link into your browser. It's not elegant. It's honest, and it saves the client from concluding your careful work is broken when it's the container that's failing them.

03 · The Deeper PointWhose failure is this, really?

Here is the part that sits uncomfortably with us. Every time we tell a client "just copy and paste this into Safari", we are papering over a real UX failure — on a major platform's behalf, with our own credibility. The instruction works. It also quietly trains people to expect that links are unreliable and that the fix is their job.

It shouldn't be. The shareable link is a promise: tap this and you'll see the thing. When the promise breaks inside a billion-user app, the user doesn't file a bug with that app — they lose a sliver of trust in the destination, which is usually a small business that did nothing wrong. The platform pockets the convenience of keeping users inside its app, and someone else pays the reputation cost.

There's a quieter cost too. Every "open this in Safari" instruction adds a micro-step of friction to a journey that was supposed to be frictionless. For a small business sending a menu, a booking page or a proposal, that extra step is exactly where people drop off — not because they're unwilling, but because the moment of intent is fragile and a copy-paste detour is enough to break it. We are, in effect, asking the visitor to do unpaid QA on a platform's behalf.

And yet — until the platforms ship better webviews, complaining about it is not a strategy. The responsibility, fair or not, is ours. We can build for the worst viewer, test through the real channel, and keep the first screen light enough that even a hostile webview can't ruin it. That's within our control. A sharper Instagram browser is not.

04 · ClosingA small UX limp.

Every link we send now carries a tiny printed note: "Best opened on desktop. If the page seems off, copy and paste it outside Instagram." It's a small UX limp, and we notice it every time we add it. We'd like to retire it. Until then, design accordingly.