What Is Browser Isolation and How Does It Work?
Browser isolation runs web content somewhere other than your device — a remote server, a container, or a restricted local process — and sends only the rendered result to your screen. The point is to keep malicious or unknown code from executing on the endpoint that holds your data. It fits any situation where users must reach untrusted sites (open web research, OSINT, third-party portals) but the device or network can't absorb the risk. It is not a substitute for endpoint protection or patching; it changes where code runs, not whether code is dangerous.
The problem it solves
Normal browsing executes a site's JavaScript, renders its HTML, and loads its assets directly on your machine. That means a compromised site, a malicious ad, or a zero-day in the browser engine runs with your user's privileges, on your network, next to your files.
Browser isolation breaks that direct execution path. The risky content runs in a disposable environment; the user's device receives pixels, a filtered document, or a sanitized page.
The main approaches
| Approach | Where content runs | What reaches the endpoint | Typical fit |
|---|---|---|---|
| Remote browser isolation (RBI) | A remote server or container | Streamed pixels / rendered session | High-risk users, untrusted sites, zero-trust programs |
| Local / container-based isolation | A sandbox or container on or near the device | Isolated session, discarded after use | Managed fleets wanting lower latency |
| DOM / HTML filtering | Rewritten in transit | Sanitized page with scripts stripped | Read-only browsing, lower-risk content |
These are not mutually exclusive. A deployment can stream high-risk sites remotely and filter low-risk ones locally.
How an isolated session works
- Request interception — The user's browser or a proxy routes the target URL to the isolation service instead of fetching it directly.
- Remote execution — The service opens the page in a controlled browser instance (often containerized) with no access to the user's file system, credentials, or local network.
- Rendering and streaming — The remote instance renders the page and streams the visual output to the user, or returns a sanitized document. Kasm Workspaces describes this as container streaming: containerized workspaces delivered to the browser.
- Input relay — Keystrokes, clicks, and scrolls travel back to the remote session.
- Disposal — When the session ends, the container is destroyed, so anything the page dropped disappears with it.
The user sees a working browser. The endpoint never executes the site's code.
Where it gets used
- Web research and OSINT — Analysts open unknown or hostile sites without exposing their own machine or identity. Kasm lists OSINT workloads and web research as explicit use cases.
- Accessing untrusted sites — Links from email, chat, or third parties open in isolation by policy.
- High-risk users — Executives, journalists, and administrators whose compromise is costly.
- Regulated and defense environments — Healthcare, financial services, government, and defense organizations use isolation to meet cybersecurity and industry standards, per Kasm's industry pages.
- Cross-enclave access — Reaching content in one security zone from another without bridging the networks directly.
Trade-offs to weigh
- Performance — Streaming pixels adds latency versus local rendering. Container-based or local isolation narrows the gap; remote streaming over long distances widens it.
- Compatibility — Some sites break under filtering or behave differently in a streamed session. Test your critical apps before rolling out broadly.
- Deployment model — Cloud is faster to stand up; on-prem or hybrid keeps traffic and data inside your perimeter. Kasm supports both, and publishes a cloud-vs-server comparison to help choose.
- Cost and licensing — Kasm offers a free Community Edition for individuals, nonprofits, and testing, plus paid editions and support subscriptions. Check the current feature matrix and pricing for your scale rather than assuming a tier covers your needs.
- Scope — Isolation protects against web-delivered threats. It does not replace patching, email security, or identity controls.
Choosing between options
If your priority is maximum containment for untrusted content, remote browser isolation with disposable containers is the strongest fit. If latency matters more than absolute separation, local or container-based isolation on managed devices is a reasonable middle ground. If you mainly need to strip active content from pages, DOM filtering is lighter but offers less protection against browser-engine exploits.
For a concrete evaluation: pick five sites your users actually visit — including one known to be script-heavy — run them through each candidate approach, and measure load time, breakage, and whether file downloads and uploads still work. That test tells you more than a feature list.