Troubleshoot the most common reasons MagicBrowse cannot start or render a visitor page correctly.

MagicBrowse depends on the visitor session, your website assets, and the network path between Crisp, your website, and the visitor browser. Most issues come from privacy settings, local environments, restrictive security rules, or blocked WebSocket connections.

Check visitor privacy settings

Crisp respects visitor privacy choices. If the visitor enabled Do Not Track in their browser, or uses a browser or extension that blocks tracking by default, Crisp cannot start the co-browsing session.

Privacy-first browsers and extensions can also block the data MagicBrowse needs to mirror the page. In that case, the session cannot be forced from Crisp.

User privacy choices permission

If User privacy choices is enabled, Crisp asks the visitor for permission before starting MagicBrowse. The visitor must be able to see and accept that prompt.

You can review this option from Crisp in Settings → Chatbox Settings → Chatbox Security → User privacy choices (MagicType, MagicBrowse).

Check where the website is loaded

MagicBrowse needs Crisp servers to access your website. If you test on localhost or a private development URL, Crisp cannot fetch the page and the rendering may fail or appear without CSS.

Check the visitor session

MagicBrowse is a live feature. If the visitor has left the page, disconnected, or appears offline, Crisp cannot connect to their current webpage.

The visitor list may also take a few seconds to update, so a recently disconnected visitor can still appear available for a short moment.

Check page weight and assets

To protect performance and visitor data usage, MagicBrowse may be blocked when a webpage is too heavy. As a rule of thumb, keep the page HTML lean and avoid embedding large assets directly in the page source.

To reduce page weight:

• Move inline stylesheets → keep CSS in external files instead of embedding large style blocks in HTML
• Remove duplicated HTML → avoid repeated markup that inflates the page source
• Avoid inline Base64 images → serve images as regular files instead of embedding them directly in HTML

CSS does not render correctly

If the mirrored page appears unstyled or broken, check whether CSS assets are blocked by your Content Security Policy or by another security layer.

MagicBrowse may also have trouble detecting styles injected dynamically with style.sheet.insertRule(), such as some setups using Emotion, styled components, or UI libraries. When possible, inject CSS as text content inside generated <style> tags instead.

Example with Emotion:

import createCache from "@emotion/cache";
import { CacheProvider } from "@emotion/react";

const emotionCache = createCache({ key: "css", speedy: false });

<CacheProvider value={emotionCache}>
  // Your app's code
</CacheProvider>

Refer to your CSS library documentation to adapt the setting to your project.

Check WebSocket and CSP restrictions

The Crisp chatbox and the Crisp operator app use WebSockets to exchange MagicBrowse data. If a firewall, proxy, browser extension, or restrictive Content Security Policy blocks the stream socket, MagicBrowse cannot connect.

What to verify:

• CSP rules → allow the Crisp domains required by your setup
• Firewall or proxy inspection → make sure secure WebSocket traffic to Crisp is not blocked
• Shopify or custom middleware → check that authentication layers do not block Crisp from fetching required page data

If none of these cases apply

If MagicBrowse still fails after checking privacy settings, public website access, visitor availability, page assets, CSP, and WebSocket access, contact Crisp support with a test URL and one or two recent conversation examples. This gives the team enough context to reproduce the issue faster.

Updated on: 03/05/2026