How browser screen sharing works

Every modern desktop browser has a built-in feature for capturing the screen. A web page can ask for it, but it cannot take it. The browser shows its own picker, you choose a tab, a window or a whole screen, and only then does the page receive a live video of that choice. The page never sees anything you did not select.

That video is not a file. It is a stream, a steady flow of frames that the browser produces for as long as you keep sharing. The next question is how to get that stream to somebody else without uploading it to a big server first.

The answer is a technology called WebRTC, short for Web Real-Time Communication. It is the same family of technology that browser-based video calls use. WebRTC lets two browsers set up a connection to each other, a peer connection, and send video, audio or small messages across it.

Two peers cannot just start talking. Neither knows where the other one is, what it can accept or what formats it understands. So before any video moves, they exchange a few small notes. One side sends an offer that says, roughly, "here is the kind of video I can send." The other replies with an answer. Along with those notes they swap a list of possible network routes, called ICE candidates. All of that is called signaling.

Signaling needs a go-between, because the two browsers cannot yet reach each other. In Help99 that go-between is our server, which passes those small notes back and forth over a live connection while the page is open. It carries the introductions, not the picture. Once the two browsers have agreed on a route, the video itself is meant to flow between them.

Most computers sit behind a home or office router, which gives them a private address that means nothing on the wider internet. For a peer to be reached, it needs to know what its address looks like from the outside.

That is the job of a STUN server. Your browser asks it, in effect, "what address do you see me coming from?" The reply is a public address and port. The browser puts that into its list of candidate routes, and the other side tries each one. If a route works, the two browsers are connected directly. That is the cheapest and usually the fastest outcome, because nobody sits in the middle.

STUN is a lightweight lookup. It does not carry your screen. It only helps two browsers find one another.

Direct routes do not always work. Some corporate networks, some VPNs and some strict routers refuse to let two outsiders connect straight through. When every direct route fails, WebRTC has a fallback: a TURN server. It is a relay. Each browser connects out to the relay, and the relay passes the traffic along.

Think of it as two people who cannot walk to one another through a locked gate, so each walks to a friendly post office and the post office hands the parcels across. The parcels pass through a third party, but WebRTC media is encrypted between the two browsers, so the relay moves it along rather than reading it. That encryption is part of the WebRTC standard, not a special feature we added.

A relay costs more to operate and adds a little delay, which is why it is the fallback and not the first choice. In Help99 the browser is given temporary relay credentials when a connection starts, and it tries direct routes first. There is also a safety net: if the temporary relay credentials cannot be issued for some reason, the customer still gets into the consultation using STUN only. On a restrictive network that might mean the connection cannot be made, but the person is not blocked at the door.

Here is the whole sequence as it happens when someone shares their screen with a support agent. The agent gives a six-digit code. The customer enters it and the page joins the consultation. The customer agrees to share and chooses a screen in the browser's picker. The two pages swap their offer, answer and candidate routes through our server. The browsers test the routes, settle on a direct one if they can or on the relay if they cannot, and the video starts to flow.

From then on, our server keeps passing small control messages and the chat, while the picture travels over the peer connection. If you want to know what the code step is about, the article on what happens when you press Share goes through it, and the screen-sharing guide shows the customer's side with screenshots.

It is worth being honest that a peer connection depends on things nobody here controls: the browser, the operating system's permission for screen capture, and the networks at both ends. A very strict network can block even the relay. A browser without screen capture support cannot start a share at all, which is the case for phones and tablets today.

Our usage counting also relies on the connection state that browsers report. A connection can be reported as connected while the picture is stuck, and we say so openly on the company page, rather than pretending that a connected state proves a good picture.

If you are a customer with a code in your hand, you can go straight to the code-entry page. If you run a support team and want to see what this costs, the pricing summary is a single short section.