ENBrowser isolation is a security approach that runs web content in a separate environment. Untrusted code does not need to execute directly on a user device. Remote browser isolation, often shortened to RBI, runs the session on external infrastructure and sends an interactive view of the page back to the user.
A person can use the website while its code runs away from company files, local applications, and the internal network.
The exact protection depends on the architecture. Download rules, form input, clipboard access, uploads, and session cleanup all affect the result.
| Item | What It Means |
|---|---|
| Main Goal | Keep Untrusted Web Execution Away from User Devices and Networks |
| Common Model | Remote Browser Isolation, or RBI |
| Execution Location | Cloud Infrastructure, Private Infrastructure, or a Local Sandbox or Virtual Machine |
| Content Sent to the User | Pixels, Drawing Instructions, or Reconstructed Page Content |
| Common Controls | Downloads, Uploads, Clipboard, Printing, and Form Input |
| Main Limit | Browser Isolation Does Not Guarantee Anonymity or Replace Endpoint and Identity Security |
What Is Browser Isolation?
A modern browser runs code from many sources. A normal page may load scripts, ads, embedded tools, fonts, and media from several domains. Most of that content is harmless. Some of it may be compromised, malicious, or built to exploit a browser flaw.
Browser isolation changes where that content runs. An isolation service opens the page inside a controlled environment. The local browser no longer has to process every page close to user data and the operating system.
The security model is containment. It does not need to prove that every page is safe before the user can view it. If the page contains harmful code, the aim is to keep the effect inside the isolated session.
Local isolation uses a sandbox or virtual machine on the user device. Remote isolation moves web processing away from the device. The same distinction appears in CISA browser security guidance.
Remote isolation is the meaning most people have in mind when they use the term browser isolation. It is also called remote browsing or web isolation.
How Does Browser Isolation Work?
The basic flow has six steps.
- A user opens a link or enters a web address.
- A security policy decides whether the request needs isolation.
- An isolated browser fetches the page and runs its active content.
- The service applies rules to actions such as downloads, uploads, clipboard use, and form input.
- The user device receives an interactive visual or reconstructed version of the page.
- The isolated session is reset, deleted, or retained according to company policy.
Mouse clicks and keyboard input travel back to the isolated session. The remote browser responds, then updates the view on the user device. The page can still feel like a normal website even though the main execution happens elsewhere.
Policies vary. Some organizations isolate all public web traffic. Others isolate unknown sites, newly registered domains, links from email, or pages that fall into risky categories.
The session is often disposable. This helps remove files and code left inside the remote environment. It does not mean every RBI product deletes every cookie or session after each tab closes. Persistence is a product and policy choice.
Types of Browser Isolation
Remote Browser Isolation
RBI runs the browser on infrastructure outside the user device. The environment may be hosted by a security provider or in a public cloud.
Running the session remotely puts more distance between web code and the endpoint. It also gives security teams one place to apply policy. The tradeoff is reliance on the isolation service. Network delay, provider access, logging, and data location all need review.
On-Premises Browser Isolation
An organization can run isolated browsers on infrastructure it manages. The web session is still separated from the endpoint, but the servers remain under company control.
This can help when data location or access to private applications matters. It also moves more work to the organization. Capacity planning, browser updates, network separation, and session cleanup become internal responsibilities.
Client-Side Browser Isolation
Client-side isolation runs web content on the user device inside a sandbox, container, or virtual machine. It can offer lower delay because the session does not need to run in a distant data center.
The security boundary is closer to the endpoint. Its strength depends on the operating system, hypervisor, sandbox rules, and update process. Malicious content still reaches the device, even if it runs inside a restricted environment.
Clientless isolation is not another execution location. It usually means the user can reach a remote isolation service through a standard browser without installing a dedicated application.
How Does Isolated Web Content Reach the User?
Browser isolation products do not all return pages in the same way.
Pixel or Video Streaming
The remote browser renders the page and sends visual frames to the user. Active page code stays in the remote environment.
Pixel streaming creates a clear execution boundary. It can also use significant bandwidth. Text selection, accessibility features, media, and visual quality may feel different from a local page.
Drawing Command Remoting
Some services send drawing information rather than a full video stream or the original website code. The local browser uses those instructions to display the page.
Drawing instructions can reduce bandwidth and preserve interactivity. Security depends on the remoting protocol and the local component that processes the data.
DOM Reconstruction and Sanitization
Another approach loads the page remotely, rewrites its structure, removes content considered unsafe, and sends a reconstructed page to the endpoint.
Reconstructed pages can feel closer to ordinary browsing. Some reconstructed code still runs locally. The result depends on how accurately the service can rewrite complex pages and handle third-party content.
These delivery methods are also covered in the Cloudflare browser isolation overview. In practice, products may combine them or choose different methods for different content.
What Threats Can Browser Isolation Reduce?
Browser isolation is most useful against threats that start inside web content.
- Drive-by downloads that try to place a harmful file on the endpoint
- Malicious scripts that target a browser vulnerability
- Malvertising delivered through a legitimate advertising network
- Redirects that send users to compromised pages
- New browser exploits that do not yet have a patch
- Web-based delivery of ransomware or other payloads
RBI can reduce the chance that an exploit reaches the local operating system because the page runs in the remote environment. That is a meaningful advantage. It is not the same as removing every path from the web to the endpoint.
Downloads need their own policy. A service may block them, scan them, sanitize them, or open them in a remote viewer. If the service simply passes the original file to the endpoint, the isolation boundary no longer covers that file.
Phishing needs similar care. A remote phishing page can still look convincing. RBI becomes more useful when the security policy blocks form input on risky sites, limits clipboard access, or shows a clear warning. Identity protection and email security still matter.
Browser Isolation Benefits and Use Cases
The strongest benefit is reduced exposure to unknown web code. Security software does not need to classify every script correctly before the page opens. The code can run inside the isolated environment while the user receives a controlled view.
Isolation is useful when blocking the whole website would interrupt legitimate work.
Common use cases include:
- Opening links from unfamiliar senders
- Researching new or uncategorized websites
- Giving contractors access to browser-based applications
- Protecting staff with privileged accounts
- Viewing documents without downloading the original files
- Accessing company applications from unmanaged devices
- Applying stricter controls to uploads, copy actions, and printing
Browser isolation often sits beside a secure web gateway, data loss prevention controls, and identity tools. The gateway decides which traffic is allowed or inspected. RBI controls where active page content runs. One does not make the other unnecessary.
Browser Isolation Limitations
RBI solves a specific problem. It should be judged on that problem, not on broad claims about safe browsing.
Performance and Compatibility
Remote rendering adds another system between the user and the website. Rich media and interactive applications may feel slower. Printing, drag and drop, browser extensions, security keys, graphics features, and device access may require special support.
Data Transfer Still Needs Policy
Users can move data through uploads, downloads, forms, the clipboard, and printing. Isolation does not decide which transfers are acceptable. Those decisions need policy and, in many cases, data loss prevention controls.
The Provider Can Become a New Trust Point
The isolation service handles web requests and may process credentials or business data. Administrators may log visited addresses, policy events, downloads, and other activity. Organizations should review encryption, retention, tenant separation, data location, and provider access.
Coverage May Be Incomplete
Traffic that bypasses the isolation route receives no RBI protection. This can happen when a different browser, application, protocol, or unmanaged device falls outside the policy.
It Is Not an Anonymity Tool
The website still sees a network address and a browser fingerprint from the isolated environment. It can also identify a person through login details and submitted data. Browser isolation does not provide anonymous browsing on its own.
Browser isolation also does not replace software updates, endpoint protection, secure authentication, or careful user decisions. It adds a useful boundary. It does not remove the rest of the security model.
Browser Isolation Compared with Sandboxing and Site Isolation
The terms sound similar, but they describe different boundaries.
| Feature | Browser Isolation or RBI | Browser Sandboxing | Site Isolation |
|---|---|---|---|
| Main Boundary | Web Execution and the Endpoint | Browser Process and Operating System Resources | Data and Renderer Processes for Different Sites |
| Usual Location | Remote, Private, or Local Isolated Environment | Local Device | Inside the Local Browser |
| Main Goal | Contain Web Threats | Limit Damage from a Compromised Process | Make Cross-Site Data Theft Harder |
| Moves Page Execution Away from the Endpoint | RBI Does | No | No |
| Separates Account Cookies | Not Necessarily | No | No |
A sandbox restricts what a process can access. RBI may use a sandbox, a container, or a virtual machine as part of its architecture. The sandbox is one control inside the larger isolation design.
Site Isolation places pages from different sites into separate renderer processes. This makes it harder for a malicious site to steal data from another site. The pages still run in the local browser. Site Isolation also does not create a separate login environment for each account.
Browser Isolation vs Browser Profile Isolation
Profile isolation is often confused with browser isolation because both separate browser activity. The key question is what gets separated.
| Feature | Browser Isolation or RBI | Browser Profile Isolation |
|---|---|---|
| Primary Question | Where Does Untrusted Code Run | Which Profile Stores This Browser State |
| Separates | Web Execution from the Endpoint or Network | Cookies, Storage, Login State, and Settings between Profiles |
| Main Use | Threat Containment | Reusable Session and Workflow Separation |
| Malware Protection | Can Reduce Endpoint Exposure | Not a Malware Containment Guarantee |
| Browser Fingerprint | The Remote Browser Still Presents One | A Profile Tool May Manage Fingerprint Settings |
| Network Identity | Depends on Service Egress | Depends on Profile Proxy and Network Settings |
Cookie isolation keeps cookie state inside the correct site, container, or profile. Session management covers how a website creates, validates, expires, and revokes login sessions. Neither one answers where potentially hostile page code executes.
A browser profile can prevent two authorized accounts from sharing the same cookie jar. It cannot promise that a malicious page will stay away from the operating system. A remote isolated browser can contain web code without providing the persistent account environments that a profile tool is built to manage.
Browser Profile Isolation in MoreLogin
MoreLogin focuses on reusable browser profiles for authorized account and team workflows. Each profile can keep its own cookies, storage, login state, proxy settings, and fingerprint configuration.
Teams can return to the correct client or project environment without mixing browser state. A multi-account browser keeps those profile environments separate and reusable as the number of accounts grows.
Within MoreLogin, the profile settings cover cookies, proxy details, account data, and advanced options.
MoreLogin profile isolation should not be described as remote browser isolation. It does not mean that suspicious web code runs on a separate RBI service. It also does not guarantee that websites cannot connect activity through account information, network data, fingerprints, or behavior.
For teams that need persistent and separate browser environments, the MoreLogin multi-account browser provides profile controls, team access, and automation support. Its value here is clean profile separation, not a claim of complete endpoint protection.
Key Takeaways
- Browser isolation keeps untrusted web execution behind a controlled boundary.
- RBI runs the web session away from the endpoint and returns an interactive view.
- Downloads, form input, uploads, clipboard actions, and policy coverage affect the protection.
- Browser sandboxing, Site Isolation, cookie isolation, and profile isolation solve different problems.
- MoreLogin manages separate browser profiles. It should not be treated as an RBI security service.
Browser Isolation FAQ
What is browser isolation in simple terms?
Browser isolation opens web content inside a separate environment. The user can interact with the page, while its active code runs away from the local endpoint or inside a restricted local boundary.
What is remote browser isolation?
Remote browser isolation runs a web session on external infrastructure rather than on the user device. It sends a controlled visual or reconstructed version of the page back to the local browser.
Is browser isolation the same as a sandbox?
No. A sandbox limits what code or a process can access. Browser isolation is the broader security approach. It may use sandboxes, containers, or virtual machines to build the isolation boundary.
What is the difference between browser isolation and Site Isolation?
Browser isolation separates web execution from an endpoint or network. Site Isolation separates different websites into different renderer processes inside a browser. The pages still run on the local device.
Can browser isolation stop phishing?
It can reduce phishing risk when policies block form input, clipboard use, or downloads on risky pages. Remote rendering alone does not stop a user from trusting a convincing fake login page.
Does browser isolation block malware downloads?
Not automatically. The product must block, scan, sanitize, or remotely display the file. If the original file reaches the endpoint, it needs separate protection.
What are the disadvantages of RBI?
Common concerns include network delay, bandwidth use, website compatibility, cost, activity logging, data location, and dependence on the isolation provider.
Is browser isolation the same as browser profile isolation?
No. Browser isolation controls where web code runs. Profile isolation keeps cookies, storage, login state, and browser settings separate between reusable profiles.
