On this page
Someone in your network taps the link in your LinkedIn post — the demo signup, the gated whitepaper, the event registration, the newsletter you actually want them to subscribe to. They came in warm: they read the post, they wanted the thing. Then the destination opens inside LinkedIn's in-app browser, asks them to sign in, and the single sign-on button they expected — "Continue with Google," "Sign in with LinkedIn" — either does nothing or kicks them to a login form on a phone keyboard. They're mid-scroll on LinkedIn, the feed is one swipe away, and the friction wins.
Most of them swipe back. It doesn't show up as a broken link anywhere — it shows up as a low click-to-conversion rate that looks like a messaging problem and isn't. The link worked. The browser it opened in didn't.
why links break in LinkedIn
LinkedIn's mobile app doesn't hand your link off to Safari or Chrome. It opens it inside its own in-app browser — a webview embedded in the LinkedIn app, with its own isolated cookie jar that shares nothing with the visitor's real browser. That distinction is the whole problem.
The visitor's logged-in sessions — their Google account, their SSO identity provider, their existing accounts on the B2B tool you're linking to — all live in Safari or Chrome. The LinkedIn webview can't see any of them. So a destination that's gated on the visitor being logged in (which describes most B2B software, every SSO flow, and any checkout that recognizes a returning customer) renders a login wall instead of the thing they came for. SSO bounces. OAuth redirects break mid-handshake. The "you're already signed in, continue" path that would've taken one tap becomes a full re-authentication on a cramped keyboard.
We named this problem the vanishing visitor and wrote the full mechanism explainer there. The short version for LinkedIn: the session that proves who your visitor is lives in their real browser. LinkedIn opens your link in a webview with an empty cookie jar. The destination can't recognize them, so it asks them to start over — and a B2B audience tapping from a feed doesn't start over.
the LinkedIn links that break most
These are the destinations where the in-app-browser cookie-jar problem bites hardest — the ones a LinkedIn audience taps and a login wall swallows. Each writeup covers the specific mechanism:
- magic-link login in an in-app browser — the email-link sign-in flow that lands in the wrong browser and loops back to a login screen
- OAuth redirect broken in an in-app browser — the "Continue with Google / LinkedIn" handshake that breaks mid-redirect inside the webview
- passkeys in an in-app browser — why Face ID / passkey sign-in won't fire inside LinkedIn's embedded browser
- Eventbrite checkout in an in-app browser — event registration that stalls at payment because the checkout can't reach the saved session
- beehiiv subscribe in an in-app browser — the newsletter signup that fails to confirm from inside the webview
- SoundCloud link in an in-app browser — the app handoff that never fires, leaving the logged-out web player
- Vinted link in an in-app browser — the marketplace link that opens to a logged-out page instead of the app
If the destination you're linking to needs the visitor logged in, the mechanism is the same — and linkboo's escape flow applies. The full destination index is here.
what linkboo does
linkboo replaces the raw URL you put in your LinkedIn posts, profile, and company page with a link-in-bio page (or a direct-route link — your choice) that has the in-app browser escape flow built into every outbound click. When someone taps your linkboo link from inside LinkedIn's webview, linkboo detects it and bounces the destination out to the visitor's real browser — Safari on iOS, Chrome on Android — where their logged-in sessions live, before the destination page loads.
The visitor never sees a friction prompt or has to know what "open in browser" means. They tap, the destination opens in their real browser, and they're already signed in.
Concretely, for LinkedIn this means:
- SSO and OAuth work the first time — "Continue with Google / LinkedIn" fires in the real browser where the identity session lives, instead of dead-ending in the webview
- Login walls don't appear — gated B2B destinations recognize the returning visitor because their session cookie is reachable
- Checkout and registration survive the handoff — event signups and saved-payment flows complete instead of stalling at a re-auth prompt
- Graceful fallback — if a destination has an app, the link opens it directly; if not, it lands in the real browser, not the cookieless webview
linkboo is also a full link-in-bio page — multiple links, themes, profile photo, the things you'd expect from a Linktree or Beacons alternative. The escape flow is the wedge.
who this hits hardest
If LinkedIn is where you do business development, recruiting, or B2B demand-gen, this is your conversion leak. The whole value of a LinkedIn audience is that it's professional, high-intent, and gated behind logins they already have — which is exactly the audience the in-app browser strands at a sign-in wall. The warmer your traffic, the more it stings to lose it at the handoff.
We wrote the LinkedIn-specific playbook for this — what breaks, who it costs, and how the escape flow recovers it — at linkboo for LinkedIn.
other platforms
LinkedIn isn't alone — every major app routes links through its own in-app browser, and every one of them strands logged-in visitors the same way. If you also drive traffic from elsewhere, the same fix applies:
- Instagram links not opening
- TikTok links not opening
- X (Twitter) links not opening
- Facebook links not opening
- Threads links not opening
If you're comparison-shopping the broader link-in-bio category, linkboo vs Linktree is the closest mainstream comparison.
The person who tapped your link wanted the demo, the whitepaper, the registration. Don't let LinkedIn's webview be the reason they didn't get it.