Keeping shared text sharp
A face on a video call can look a little soft and nobody minds. A line of small text that looks soft is useless. Screens are a different kind of picture, and we treat them that way.
A screen is not a face
Video-call encoders are built for people: moving faces, gestures, rooms with lighting. They are good at hiding small errors in skin tones and backgrounds. A screen is the opposite. It is mostly still, it is full of hard edges, and what matters most is exactly the thing a face-tuned encoder blurs first, thin letters on a flat background.
Screen content also changes in bursts. Nothing happens for several seconds while somebody reads, then a whole page scrolls at once. A good screen share has to keep text crisp while nothing moves and still cope when everything does.
More pixels is not automatically better
It is tempting to think that sharing at the screen's full native size must give the sharpest picture. In practice it often does the opposite. A very large capture means a large amount of data to encode and send. The computer works harder, the first seconds after connecting are slower, the frame rate can drop, and when the network cannot keep up, the encoder reduces quality to compensate.
So Help99 asks the browser for a capture whose long side is at most 1920 pixels. We cap by the long side rather than by a fixed width and height, so a tall portrait screen is not squeezed by a box meant for landscape ones. It is only a ceiling. A smaller screen is never enlarged, and the browser can deliver less than we ask for.
Frame rate: a ceiling, not a target
For frame rate, we ask for up to 30 frames per second. Thirty is more than enough to follow a cursor and a scrolling page, and asking for more would spend bandwidth that is better used on sharper individual frames. Like the size, this is a maximum. A still screen does not need thirty new pictures every second, and the browser decides how much it really sends.
Codecs: why AV1 goes first
A codec is the method used to squeeze video into something small enough to send. Browsers support several, and during connection setup the two sides agree on one both can use. The order of preference matters, because the first one that both support tends to win.
For the screen's video line we ask the browser to list AV1 first. AV1 is a newer codec that is generally good at keeping small, sharp detail at a given amount of data, which suits text. If a browser does not support AV1, nothing changes for that person: the remaining codecs keep their original order and the connection uses what the browser would have used anyway. We apply this to the screen video only and never to the voice line.
Whether AV1 is used on a particular connection depends on both browsers, and on the computer's ability to encode and decode it. We cannot tell you in advance which codec your session will end up using.
What we do not promise
We ran tests on the way to these settings, but numbers measured in a lab do not describe your connection, your laptop, your office network or your browser, so we do not quote them as promises. Real networks lose packets, change speed, and sit behind relays. A connection that is perfectly sharp on one day may be softer the next.
What we do say is simply what we ask for: a capture capped at 1920 pixels on the long side, up to 30 frames per second, and AV1 offered first for the screen video where the browser supports it. What the browser and the network then deliver is theirs to decide.
Why not simply send every pixel untouched?
Because the connection between two people is a shared, limited pipe. A raw screen at full size would need far more bandwidth than most home connections can steadily offer, and when a pipe overflows, video does not slow down politely. Frames arrive late or not at all, and what you see freezes, then jumps.
A modest, steady stream that always keeps up is more useful in a consultation than a perfect picture that stutters. The agent is usually reading a field label or a menu item, and a picture that stays calm lets them do that. That trade, a capped size and a capped frame rate in exchange for steadiness, is the heart of our choices here.
What you can do to help text stay readable
Share the smallest surface that does the job. A single browser tab has less to encode than a whole desktop, and it keeps unrelated content out of view. If the text on your screen is small, zoom the page in a notch before sharing. Zooming is the one thing that improves legibility on any codec.
Close heavy programs while sharing, and prefer a stable connection to a weak one. If the picture looks soft, give it a few seconds; the first moments of a connection are often the roughest. If it stays soft, tell your agent so they can slow down and zoom on their side.
For the background on how the connection itself is made, read how browser screen sharing works. If you have a code, you can enter it here, and teams can see what sessions cost on the company page. The screen-sharing guide covers troubleshooting.
More to read: all Learn articles and the questions and answers. Have a code? Enter it here. Guide: screen sharing, step by step. Pricing: company overview.
