Co-browsing technology lets a customer and agent view the same supported digital content, such as a webpage, and interact where permissions allow. That shared context does not itself determine the agent’s authority or what happens to the information exchanged during the session.
For contact center and CX leaders, understanding co-browsing means separating three questions: what the agent can see, what they can change and what session data is transmitted or retained. Consent, masking and encryption address different parts of that access boundary. Understanding how the session works makes those distinctions much easier to assess.
What co-browsing shares
Collaborative browsing gives both participants a common reference for a digital task without necessarily exposing the customer’s wider device. Its value is the precision that shared context brings to the conversation.
Consider an online application. A validation message appears beneath a field, but the customer cannot tell whether it concerns the format, a missing answer or a dependency elsewhere on the page. Seeing the field and message lets the agent explain the relevant requirement instead of asking the customer to reconstruct the page verbally.
That assistance does not require access to unrelated browser tabs, personal files or other applications. Nor does it necessarily require the agent to enter information on the customer’s behalf.
The supported context matters. Co-browsing is not a promise that any website, app or action can be shared. Its reach depends on the implementation and the digital journey it supports. For broader benefits and use cases, see our co-browsing overview. Here, the important question is how the shared context is created and what access accompanies it.
How a co-browsing session connects customer and agent
A co-browsing session connects the customer’s digital activity with an agent’s view of the supported content. In a customer-approved workflow, the customer or agent initiates a request, the customer approves sharing and the service connects the participants to the same session. Joining that session and receiving authority to perform actions are separate steps, even if the interface presents them together.
Once connected, the agent sees the shared context. Depending on the permissions, the agent can observe, point to an element or interact with the page. The session continues until it is ended or its access expires. Termination should stop live viewing and interaction, rather than merely dismiss a message on the customer’s screen.
The underlying technology does not always work like a camera pointed at a desktop. One implementation approach synchronizes the page’s structure, its current state and interaction events. Page structure describes elements such as labels, fields and buttons. State includes information such as which section is open or which validation message is displayed. Events describe changes, including scrolling or entering text.
In this approach, the agent’s interface reconstructs a representation of the supported page and reflects relevant updates. It shares information about the page rather than simply transmitting a video of everything the customer sees. Other architectures handle shared content differently, so this model does not describe every co-browsing service.
These differences have practical consequences. Integration requirements, supported content and any download requirements depend on how the service works. So does the data path: session information may pass through an intermediary service between the customer’s device and the agent’s interface. That path determines where sensitive information needs to be excluded or protected, not just how the shared page appears.
How this differs from screen sharing and remote desktop access
Co-browsing, screen sharing and remote desktop access differ in what they expose and how another participant can interact. Their names alone do not establish the full permission boundary.
| Technology | Shared surface | Interaction and access boundary |
| Co-browsing | Supported digital content, such as a website journey | Joint viewing and supported interactions, governed by the implementation’s scope and permissions |
| Screen sharing | A selected tab, window or display, depending on the application and browser | Shares a visual stream; remote control is a separate capability |
| Remote desktop access | A remote device session or desktop environment | Can permit device interaction within the granted permissions |
Screen sharing does not inherently expose an entire device. Sharing a browser tab is different from sharing a full display, and choosing a window excludes a different set of information. Permission to watch the visual stream does not itself grant permission to control the device.
A supported website form is a natural candidate for co-browsing because the relevant context is inside the digital journey. Diagnosing an operating-system setting calls for a different surface. Screen sharing can show that setting; remote desktop access can support direct interaction when authorized.
Select the visual capability for the task and the context required. Define the necessary surface first, then decide which interactions the agent needs. This avoids granting broader access simply because a tool makes it available.
Agreeing to share is different from authorizing an action
Customer approval should make participation understandable: who is joining, what will be shared and how the customer can stop sharing. Visible session status matters because a customer should not have to guess whether the agent is still connected. An acceptance button without that context says little about the customer’s understanding.
Starting a session, allowing interaction and allowing recording are different decisions. A clear experience explains those distinctions when they become relevant. Clicking to begin sharing does not, by itself, establish informed consent or legal compliance for every subsequent activity.
The same separation applies within the page. Viewing lets the agent understand what is displayed. Pointing or highlighting directs attention without changing the customer’s answers. Navigation changes the page or section in view. Typing changes information. Submission can create a commitment or send information for processing. Treating these as a single permission obscures consequential differences.
In the application example, explaining a validation error is assistance. Entering a corrected answer changes the application. Submitting it is another action again. A service design can reserve submission for the customer or require an explicit confirmation, but those restrictions need technical enforcement if they are intended to prevent agent action. An instruction in an agent handbook is a policy, not a disabled submit button.
Restrictions need not make collaboration ineffective. An agent who can see the relevant error and point to the correct field can still give precise help while the customer supplies the answer and submits the application. Where agent input is useful, permission can be designed around that task without assuming that every available action should follow.
What masking hides, and what it does not establish
Masking obscures sensitive content, but its location determines what it protects. A password or payment value hidden in the agent’s interface is evidence about the agent’s view. It does not establish whether the original value reached an intermediary service before being hidden.
Excluding a value on the customer’s device before it enters the co-browsing data stream creates a different boundary from concealing it when the agent’s interface renders the page. Neither description alone explains what diagnostic logs or recordings contain. Recording protection also depends on where recording occurs: capturing an already-masked interface is different from retaining underlying session content.
Follow a sensitive value through the application journey. The customer enters it into the website. The website needs it for its own processing, but the assistance session does not necessarily need it. The questions are whether the co-browsing component collects the value, whether it transmits it, what any intermediary receives and what reaches the agent. Retained records introduce another destination. Excluding information from assistance does not mean preventing its legitimate submission to the website itself.
Visibility and editing are separate controls. Concealing an answer does not automatically prevent an agent from changing it. A protected field therefore needs an explicit decision about both disclosure and interaction.
Coverage also depends on how the page changes. A form can reveal additional fields after an answer, and a website release can introduce a new sensitive input or change its structure. If protection rules depend on identifying particular elements, those changes affect the rules’ coverage. A masked field on the initial page does not establish protection for a newly revealed field.
Ending live access does not delete retained records
Security controls answer different questions at different points in the session. Agent authentication establishes the agent’s identity. Session admission controls determine who can join a particular interaction. Authorization determines what that participant can do after joining. An authenticated agent still needs appropriate access to the specific customer session.
Encryption protects defined data flows or stored information against unauthorized reading. It does not decide whether the service should collect a sensitive value or whether the agent should submit an application. Those are collection and authorization decisions. An encrypted connection can carry information that the assistance task never needed.
Expiry limits how long an invitation, credential or permission remains usable. Revocation removes access when permission is withdrawn. Both matter: allowing an invitation to expire later is not a substitute for ending an active agent connection now. A successful customer stop action should remove live access and prevent reconnection under the withdrawn authorization.
Retained records follow a separate lifecycle. An event log can record session identifiers, participants and start or end times without containing the customer’s form answers. Captured session content is different evidence with different exposure. Recordings, where enabled, require their own decisions about access, storage and retention.
Ending the live connection does not automatically delete those records. Their permitted uses, authorized viewers and deletion schedule must be defined separately. Documentation should distinguish event metadata from captured content rather than group everything under the label ‘session logs.’
Consent, masking and encryption are established controls. Their value depends on applying each to the right problem. None alone establishes appropriate authorization, necessary collection and dependable termination across the whole session.
Keep the boundaries aligned with the live customer journey
A co-browsing implementation needs to remain aligned with the journey customers actually use. Architecture determines which controls are possible. Configuration applies them to pages, fields and actions. Operating practices keep those choices dependable when the website or service workflow changes.
An implementation demonstration should make the boundaries concrete. In a representative application journey, examine the agent’s actual view and permitted interactions, then follow a sensitive field through the documented data path and retained records. End sharing from the customer’s side and observe what the agent can still see or do. Include a changed or dynamically added field so the demonstration covers more than the initial form.
Those boundaries also need an owner after launch. Adding a field, changing a submission step or revealing new content after a selection should trigger review of the affected sharing and permission rules. The digital team understands what changed; service and security owners need to understand what that change exposes or enables during assistance. The customer’s visible controls must continue to correspond to the access the implementation actually grants.
