Co-browsing explained: what the agent can actually see
Co-browsing is a support technique in which an agent views, and sometimes interacts with, a customer's live browser session while the customer keeps control of their own device. The shared session is scoped to a single website or web application, so the agent sees that page and nothing else on the machine.
What does co-browsing mean?
The name is literal. Two people browse the same page at the same time, from two different places. The customer stays on their own screen, in their own session, logged in as themselves. The agent gets a synchronised view of that page and a cursor the customer can see.
You will also see it written as cobrowsing or collaborative browsing. Vendors sometimes call the interactive version remote form assistance. It is the same technique.
What makes it useful in support is that nobody has to describe an interface out loud. The agent stops asking which button the customer clicked and simply watches them click it.
How does co-browsing work?
- Invitation. The agent generates a short code or link, or the customer starts the session from a widget on the page. Nothing installs.
- Consent. The customer accepts explicitly. Responsible implementations do not allow a silent start, and the customer can see, throughout, that a session is running.
- Synchronisation. The page state is mirrored to the agent, usually by streaming the document structure rather than pixels of the screen. That distinction matters, because it is what makes selective masking possible at all.
- Interaction. Depending on how the session is configured, the agent may only point and highlight, or may be granted permission to type into fields and click.
- Termination. Either side ends it, and the customer can end it at any moment without ending the call.
How co-browsing differs from screen sharing
These get used interchangeably and they are not the same thing, which is worth being precise about because the difference is a privacy difference.
Screen sharing broadcasts a picture of the customer's display. Whatever is visible is visible: the other tabs, the notification that just arrived, the file names on the desktop, the personal email in the background. Masking is not really possible, because the sending side is sending pixels.
Co-browsing shares the structure of one page in one browser context. The agent has no view of other tabs, other applications, or the desktop. And because the session is built from page elements rather than pixels, individual fields on that page can be hidden before the data ever reaches the agent.
Practically: screen sharing is broader and blunter, co-browsing is narrower and controllable. Support teams handling account data usually pick the second for that reason.
The privacy controls a responsible implementation has
- Field masking. Named fields are excluded from the stream at the source, so card numbers, passwords, national identifiers and dates of birth never reach the agent's browser at all. Masking that happens on the agent's side is not masking, it is a blindfold on data that has already travelled.
- Explicit, visible consent. The customer opts in, and the interface keeps showing that the session is live.
- Scoped domains. The session only works on the pages the business owns. Navigating away ends or pauses the share.
- Graded permissions. View only by default. Remote control granted per session, per field, and revocable.
- Audit logging. Who joined, when, for how long, what was masked. This is what makes the control demonstrable rather than claimed.
Where payment data appears on the page, the masking requirement is not optional. The PCI Security Standards Council's PCI DSS version 4.0 requirement 3.4.1 states that the primary account number must be masked when displayed, with at most the first six and last four digits visible, and full display limited to people with a documented business need. A co-browsing session that shows an agent a full card number is a compliance problem, not a feature.
Co-browsing explained: a checkout that keeps failing
A customer calls because an order will not go through. Three minutes of describing the form gets nowhere. The agent starts a co-browsing session, watches the customer complete the address block, and sees the postcode field silently rejecting a lowercase entry.
The agent highlights the field, the customer retypes it, and the order completes. The card fields stayed masked throughout, and the agent never saw anything outside that one page.
When co-browsing is the wrong tool
It only reaches problems that live inside a browser. A leaking appliance, a damaged parcel, a warning light on a dashboard, a part that arrived bent: none of those are visible to a co-browsing session, and no amount of screen access changes that. Those belong to the camera based half of visual support, either live through remote assistance or through an asynchronous capture the customer completes on their own time.
It also needs both people present at once. Co-browsing is inherently live, so it carries the scheduling cost that goes with every live technique, and it does not help a customer who gave up at eleven at night.