Every web page you open is a small program. It ships JavaScript, WebAssembly, fonts, images, and stylesheets, and your browser runs all of it. Browser vendors work hard to sandbox that code, and modern browsers are genuinely good at it. But sandboxes have escapes, and a single unpatched flaw in the rendering engine can let a page reach the rest of your system. That is the class of attack, the drive-by exploit, that remote browser isolation (RBI) is designed to make irrelevant.
The idea is simple to state. Instead of rendering a risky page on your laptop, a remote server renders it inside a throwaway container. Your device receives only a safe representation of the result. If the page carries an exploit, it detonates on the remote container, which is torn down seconds later along with anything the attacker managed to plant. The endpoint never ran the hostile code.
Two Ways to Send the Page Back
The interesting engineering question is what counts as a "safe representation," and there are two dominant answers with very different tradeoffs.
Pixel pushing
In the pixel-streaming approach, the remote browser fully renders the page and streams the visual output to your device as a sequence of images or a video-like feed, similar to a remote-desktop session scoped to one tab. Your keystrokes and mouse movements travel the other way. Because your device only ever receives pixels, no page code of any kind reaches it. This is the strongest isolation available, and it is the reason pixel pushing is favored for the highest-risk browsing.
The cost is bandwidth and latency. Streaming a live rendering of every page is heavy, text can look slightly soft, and a slow link makes scrolling feel laggy. It also runs into copy-paste and accessibility friction, since the local device sees an image rather than real text.
DOM reconstruction
The second approach rebuilds a cleaned version of the page. The remote browser parses the site, strips or neutralizes active content, and sends your device a sanitized document object model, the HTML and CSS structure, which your local browser then renders normally. Because real markup arrives, text stays crisp, pages feel native, and bandwidth is far lower.
The tradeoff is the mirror image of pixel pushing. Some processing now happens on your device again, which means the isolation boundary is thinner. The sanitizer becomes the security-critical component: if it fails to strip a hostile construct, that construct reaches the endpoint. DOM reconstruction trades a margin of safety for a much better experience, and vendors tune where they sit on that line.
Pixel pushing sends only images, so no page code touches your device, at the cost of bandwidth and fidelity. DOM reconstruction sends cleaned markup for a native feel, at the cost of a thinner isolation boundary that depends on the sanitizer being correct.
What RBI Actually Defends Against
RBI is aimed squarely at code execution on the endpoint. It shuts down browser-engine exploits, malicious ads, drive-by downloads, and malware that tries to run the moment a page loads. For an organization worried about a targeted zero-day against its browser, moving execution off the endpoint changes the math considerably. Files that arrive through the isolated session can be scanned or rendered read-only before they are ever allowed down to the real device.
This is why RBI shows up in enterprise security stacks rather than on personal machines. It is a heavy control that pairs well with a policy of "open uncategorized and risky links in isolation, open trusted internal apps directly."
What It Does Not Fix
RBI is not a general privacy tool, and it is easy to overestimate. Two limits matter most.
First, it does not stop phishing that relies on you. If a page is a convincing fake of your bank's login and you type your password into it, RBI faithfully relays those keystrokes to the remote browser and onward to the attacker's server. The exploit protection is real, the credential-theft protection is not, unless the deployment layers on read-only mode or data-entry controls. We covered the human side of this in adversary-in-the-middle phishing, and RBI does nothing about it by itself.
Second, it changes who you trust rather than removing trust. The remote browser sees every page you visit in full, including whatever you type. For an enterprise running its own isolation gateway, that is an acceptable shift, since the browsing already flowed through corporate infrastructure. For an individual routing personal browsing through a third-party cloud browser, it is a genuine privacy transfer: a new operator now sits between you and the entire web. That is worth weighing against the tools in our privacy browsers comparison, which keep execution local but harden it.
| Threat | Does RBI help? |
|---|---|
| Browser-engine exploit / drive-by malware | Yes. Code runs on the disposable remote container, not your device. |
| Malicious file download | Partly. Files can be scanned or rendered read-only before release to the endpoint. |
| Credential phishing you fall for | No. Keystrokes are relayed faithfully unless data-entry controls are added. |
| Tracking / fingerprinting of your browsing | No. The isolation operator now sees everything you visit. |
Where It Fits Alongside Other Isolation
RBI is one point on a spectrum of isolation strategies. At the light end sit per-site browser sandboxes and separate browser profiles, which we discuss in browser profile compartmentalization. At the heavy end sit compartmentalized operating systems like the approach in Qubes OS, where the whole browser lives in a disposable virtual machine you control. RBI lands in between, with the distinguishing feature that the disposable machine is someone else's server rather than your own.
For most individuals, running a hardened local browser plus disposable virtual machines for risky work gets most of the benefit while keeping execution under your own control. RBI earns its place when an organization needs to protect many endpoints centrally and can accept the bandwidth cost and the operator trust that come with it.
The Layer RBI Cannot Reach
Browser isolation protects the machine that renders a web page. It says nothing about the confidentiality of the messages you send once you are past the page. Isolating execution and encrypting content are separate jobs, and a strong posture needs both: an endpoint that will not run hostile code, and a communication layer where the content is encrypted end to end regardless of what any intermediary can see.
That second job is the one we work on. Web execution is a device-integrity problem with device-integrity answers. Keeping your messages readable only by the people you send them to is a cryptography problem, and it is answered at the protocol layer, not the browser.