Rather Than Use Open Source Co-browsing We Built Our Own

Building Upscope's co-browsing solution turned out to be significantly more complicated than your typical CRUD app. Upscope is built from the ground up as there were a limited set of open source co-browsing solutions. Below are some notes from our CTO on the main challenges you might find and how to overcome them.

Related: The Ultimate Guide To Co-browsing

Passing html

We first tried getting the full html and dumping it into an iframe. That didn't work because different browsers have ways to fix broken html. If you put a paragraph in the header, chrome auto-corrects and puts it in the body. If you do it with javascript it stays there so you need to use javascript.

To pass it, we compiled the whole HTML into a JSON object including tag name, attributes and content and parsed it on the other side and built it element by element in the iframe and changed all links to the proxy server.

Proxy CSS

We need to proxy CSS because:

  1. Their server might block access to our server on the basis that it's not the same domain.
  2. You can't simulate a hover state in javascript so we need to rewrite all the hover CSS rules to something that we can set programmatically.

If the CSS is not reachable by our server, we'd make an Ajax request, encode it and send it with the rest of the page from the user's browser.

Identifying changes

We use mutation observer which is built into the browser. There's Shim for older browsers (IE 10 and 9) and that gives a notification if there are any changes on the page so you don't have to look at the document every few seconds.


To make it work with canvases, there's a call you can make to convert the canvas into a png picture. You would then compare the pictures at two points. If it's the same, nothing happens, otherwise we send over the new picture.

Server clusters

Because we have a cluster of different servers, we could not control whether some events reached the agents before others, especially events that have more data that take longer to travel through the network. Therefore we started numbering the events so that they are executed in the same order they happen on the users browser.


Because we have a scaling system for servers, sometimes a server would be removed from the cluster, several 1000 clients would seek to connect to another server quickly. But due to rate limiting, ongoing sessions would not connect right away so we had to have a preferential route for ongoing sessions. A way to bypass our own rate limit.

Get a copy of Upscope co-browsing on your server or use the API

If you're looking for more control over a co-browsing solution and don't want to build your own or use open source solutions, you can get Upscope's on-premise co-browsing solution and integrate it directly into your systems and have all data only pass through your own systems.

Here are the co-browsing REST API docs and here are the co-browsing javascript api docs on Github.

If you'd like to talk to the lead developer for the API, ping us on our chat box.

Rather Than Use Open Source Co-browsing We Built Our Own
Share this

Subscribe to Upscope Blog!