Co-browsing, screen sharing and user impersonation all let support see what a customer sees. Co-browsing vs screen sharing vs impersonation mostly comes down to one question: does the customer have to be there? Screen sharing and co-browsing are live sessions that the customer starts or approves and can watch. User impersonation lets an authorized staff member open your product as the customer, without the customer present.
Between co-browsing and screen sharing, the difference is scope. Screen sharing shows whatever screen, window or tab the customer picks. Co-browsing shares only your own web pages, and can hide sensitive fields. Impersonation is a different tool again: it uses your app’s own permissions instead of the customer’s screen.
What are co-browsing, screen sharing and user impersonation?
Screen sharing is the customer streaming their screen, an app window or a browser tab to you, usually through a meeting tool.
Co-browsing is a shared, live view of your website or web app, captured by a script on your pages. The agent watches the customer’s page and, if allowed, can click or type in it.
User impersonation is a staff member signing in to your product as a specific customer, with that customer’s permissions and without their password.
The first two are about seeing the customer’s session as it happens. The third is about reproducing what the customer’s account sees, whenever support needs to.
How does screen sharing work for support?
Screen sharing is customer-controlled by design. In a browser, the W3C Screen Capture API (opens in a new tab) prompts the user for permission, and the browser must let them choose which screen, window or tab to share every time. Browsers can’t remember that grant for next time.
The agent sees pixels, not data. They can’t click unless the meeting tool supports remote control. Microsoft Teams, for example, has a “Give control” option that lets someone interact with the shared screen. Microsoft’s advice on sharing in Teams (opens in a new tab) is to “only give control to people you trust”.
Setup cost is close to zero, since most teams already have a meeting tool. The privacy risk sits with the customer. If they share a whole screen, you may see notifications, other tabs and other apps.
Screen sharing fits problems outside your product, such as browser settings, extensions, file downloads or another tool in the workflow. It also suits walkthroughs with customers who prefer a call.
How does co-browsing work?
Co-browsing works through a script you install on your own pages. Glance, for example, asks you in its cobrowse quick start (opens in a new tab) to add its script tag to every page an agent should be able to view. Pages without the tag can’t be viewed, and the agent’s view pauses until the customer returns to a tagged page. In the simplest setup, agents join with a code the visitor gives them.
Upscope’s Co-Browsing API (opens in a new tab) works similarly. The SDK runs on your pages, and the agent connects to a visitor by an Upscope ID, your own user ID, or a four-digit code the visitor reads out. Sessions end when either side disconnects.
Co-browsing tools give you controls that screen sharing lacks. Upscope’s web SDK configuration options (opens in a new tab) include:
- Asking the visitor to authorize the session before screen sharing starts.
- Asking separately before the agent can click or type.
- Masking elements by CSS class or selector.
- Listing elements the agent can never click or type into.
Upscope’s page on what data it stores (opens in a new tab) says masked content, cookies and browser storage are never sent to its servers. Check each vendor’s own documentation, since these behaviours differ between products.
Co-browsing fits guided help on your own site: a form that won’t submit, an onboarding step or a confusing settings page. The customer is usually on a call or in chat at the same time. Setup means installing the script, reviewing what to mask, and agreeing terms with a vendor.
How does user impersonation work?
User impersonation gives a staff member a session in your app as the customer. The customer doesn’t need to be online, so it works for tickets that arrive overnight or bugs that only appear in one account.
The risk moves from the customer’s screen to your internal process. Devora’s overview for teams (opens in a new tab) describes a controlled workflow: a team member requests access with a scope, duration and reason, an administrator approves it, and your backend creates a short-lived login for that customer. A read-only scope blocks writes (opens in a new tab) except for reviewed exceptions. Only the backend guard is a real security boundary; hidden buttons aren’t. The staff member sees a banner showing which customer they’re viewing as, the scope and a countdown, as Devora’s frontend guide (opens in a new tab) describes.
Setup cost is the highest of the three. Your app has to issue and revoke the impersonation credential, recognize impersonated sessions and enforce restrictions on the backend. The multi-tenant impersonation checklist lists the responsibilities.
Co-browsing vs screen sharing vs user impersonation compared
| Screen sharing | Co-browsing | User impersonation | |
|---|---|---|---|
| Customer present | Yes | Yes | No |
| Who starts it | Customer picks what to share | Customer starts or approves, depending on setup | Staff, usually after internal approval |
| What staff see | Any screen, window or tab the customer chooses | Only pages with your co-browsing script | Your app, with the customer’s data and permissions |
| What staff can do | Watch; remote control only if granted | Watch; click or type if allowed | Act as the customer, within the scope your backend enforces |
| Main privacy control | Customer’s choice of surface | Masking and page scope | Approval, scope, time limits and audit |
| Setup | Existing meeting tool | Script on your pages, plus a vendor | Backend and auth integration |
| Best for | Problems outside your app | Live, guided help in your app | Account-specific bugs and asynchronous tickets |
Which method is safer for customer data?
Each method protects against a different risk, so “safest” depends on what support needs to see.
Screen sharing gives the customer full control but no masking. Whatever is on the shared surface is visible, including things they forgot to close.
Co-browsing narrows the view to your tagged pages and can mask fields before they leave the browser. The customer can usually see what the agent does. Its weak spot is coverage: a field you forgot to mask is visible.
User impersonation removes the customer from the loop, so it needs the strongest internal controls. It’s also the only method where you can restrict actions in your backend, for example with a read-only session that blocks writes and exports. If you record impersonation sessions, treat the recording as sensitive data. In Devora, recording is off by default (opens in a new tab), and masking defaults to hiding all text and input values.
Consent works differently too. In screen sharing and co-browsing, the customer agrees in the moment. With impersonation, your terms, privacy notice and internal approval carry that weight. Devora’s recording privacy docs (opens in a new tab) are explicit that customers remain responsible for their own end-user notice and authorization decisions.
When should you use each?
Choose screen sharing when the problem may be outside your product, the customer is happy to join a call, and you don’t want to install anything.
Choose co-browsing when you want to guide customers through your own web app in real time, you can install a script on your pages, and you want masking and page-level limits rather than full-screen visibility.
Choose user impersonation when the customer can’t be there, the issue depends on their specific data or permissions, or engineering needs to reproduce a bug in the real account. Pair it with approval, a time limit and read-only scope by default.
Many teams use more than one. A co-browsing session can answer a “how do I” question, while an impersonation session handles the bug report that arrives afterwards. Session replay is different again: it shows what happened earlier, not the account as it is now. When session replay isn’t enough covers that gap.
Where Devora fits
Devora is user impersonation tooling, not co-browsing. It has no co-browsing feature or integration, and it doesn’t stream a customer’s screen. Its docs for teams (opens in a new tab) list what it handles: access requests, approvals, read-only or read-and-write scope, time limits, access history and optional recording. Its backend scope guard (opens in a new tab) enforces the session’s scope on the routes you protect. Your application keeps ownership of authentication and the login it issues.
If you already use screen sharing or co-browsing for live help and need a controlled way to handle tickets when the customer isn’t there, create a Devora account and try one staging session.
Sources
- W3C: Screen Capture (Working Draft, August 27, 2026) (opens in a new tab)
- Microsoft Support: Share content in Microsoft Teams meetings (opens in a new tab)
- Glance: Cobrowse quick start (opens in a new tab)
- Upscope Co-Browsing API: How it works (opens in a new tab)
- Upscope Co-Browsing API: Web SDK configuration options (opens in a new tab)
- Upscope Co-Browsing API: What data does Upscope store? (opens in a new tab)
- Devora: Overview for teams (opens in a new tab)
- Devora: Scope and security (opens in a new tab)
- Devora: Frontend (opens in a new tab)
- Devora: Recording privacy and activity logs (opens in a new tab)