The slowest part of “let me just show you” is usually the install. Pick a tool — Zoom, Teams, Meet — and the first ten minutes vanish into downloads, account creation, and “is your audio working?” The point of showing your screen is to skip the back-and-forth, not stack more of it.
You don’t need an installed app for this. Modern browsers ship a standard API called getDisplayMedia that captures your screen and streams it to another browser. Linkside is built on it. No installer, no account, no admin approval — a link does the work.
This post walks through the actual flow, explains what the browser is doing underneath, and is honest about where browser-only screen sharing breaks down.
What “no install” really means
getDisplayMedia is a Web API — it lives in your browser the same way fetch or navigator.geolocation does. When a site calls it, the browser shows its own picker, you choose what to share (a tab, a window, your whole screen), and a media stream starts flowing.
Two things follow from that.
First, the browser is the one asking for permission, not the site. Linkside can’t pre-select which tab you share or quietly grab your screen; the picker is browser-controlled and the permission is fresh every time. There’s nothing for the site to “save” between sessions because the spec doesn’t allow it.
Second, the site can’t constrain the picker the way it constrains, say, a webcam. Your browser shows tabs, windows, and full screens; you choose. Constraints like resolution apply after you’ve picked, not before.
The Linkside flow, step by step
- Open the create page. Go to linkside.io/app/create. The page loads in your browser; nothing installs.
- Send the link. Linkside generates a private room URL. Copy it, drop it in chat, text it, email it. The other person clicks it in their browser.
- Click Share. Your browser shows its picker. Pick a tab, a window, or your whole screen.
- They see it. Stream is live.
The whole flow is built to fit inside the time it would have taken to describe what you wanted to show. No account creation, no email verification, no install dialog. There’s a permission prompt for screen capture — that’s the browser, not us — and that’s the only modal step.
Why the stream stays direct (and what happens when it can’t)
The bytes don’t go through a vendor’s video cluster. Linkside uses WebRTC, which prefers a direct peer-to-peer connection between the two browsers. The signaling server’s job is matchmaking — exchanging the small messages the browsers need to find each other on the open internet — and then it gets out of the way.
When direct doesn’t work (hotel Wi-Fi, restrictive corporate VPNs, double-NATs), the stream falls back to an encrypted relay. The relay forwards the encrypted bytes; it can’t read them because the WebRTC standard requires DTLS-SRTP encryption between the two endpoints, regardless of route. Both the direct and relay paths are encrypted end-to-end in transit.
A few things follow from that architecture, all worth being clear about:
- Linkside never sees your screen content. The signaling server only relays connection-setup messages, not media frames.
- Rooms are temporary. When the session ends — or after about 15 minutes of inactivity — the room is gone. There’s nothing to store and nothing to recover.
- There are no recordings. Not on our side, not as a feature you can toggle. The browser on the other end could record what it sees, the same way it could screenshot any web page; that’s a property of any screen share, including the installed ones.
We’ll cover the WebRTC handshake and STUN/TURN fallback path in separate posts as the blog rolls out.
Browser support
There are two questions here that often get conflated: what does the browser’s getDisplayMedia API support, and what does Linkside recommend for hosts? They have different answers.
The browser API is broadly supported on desktop — the picker UI and available surfaces (tab / window / screen) vary by browser, but the call works in current Chrome, Edge, Firefox, and Safari. Mobile browsers, including iOS Safari, are more limited; check MDN’s getDisplayMedia compatibility table for the current state.
Linkside’s recommended hosting and joining matrix:
| Browser | Hosting (sharing) | Joining (viewing) |
|---|---|---|
| Chrome / Edge on desktop | Recommended | Supported |
| Firefox / Safari on desktop | Limited (may have quirks) | Supported |
| Any current browser on mobile | Not supported | Supported |
| In-app browsers (Instagram, Slack, …) | Not supported | Not supported |
The short version: for hosting, use Chrome or Edge on desktop. For joining, any current browser works — including mobile. If you try to host from Firefox or Safari, things should mostly work, but our app will warn you up front that hosting from there has known quirks around the share-picker UX.
When you actually need an installed tool
Browser-native screen sharing isn’t a replacement for everything. It’s the right default for ad-hoc sharing — the kind that should have happened five minutes ago and didn’t because someone had to install something. The cases where you genuinely want an installed app are real and small:
- You need to take control of the other person’s machine. Remote-control tools like TeamViewer or AnyDesk install on both ends because they need input injection. Linkside is show-only — the viewer watches, they don’t get a mouse pointer on your screen.
- You need a cloud recording or transcription. Recording-as-a-feature requires a media server in the path. We don’t operate one; if your workflow depends on a recorded artifact, use a tool that does.
- You’re running a webinar for hundreds. WebRTC’s direct-connection model is built for small groups. A 500-person broadcast is a different architecture problem.
For everything in between — the support call, the live demo, the design review, the “look at this for a second” — a browser link is the right shape.
What this changes day-to-day
The friction we built Linkside to remove is the one between deciding to show someone your screen and them actually seeing it. When the cost of starting a share drops to a copied link, the calculus changes. You stop scheduling 30-minute Zooms for what’s really a 90-second walkthrough. You stop asking an unfamiliar customer to install your video software before you can help. You stop describing a UI and start showing it.
If you want to try it, create a room. Send yourself the link from another browser and watch the flow end-to-end. The whole pitch is that there’s nothing else to read first.