9.1 Browser Automation with the WebDriver Protocol
Key Takeaways
WebDriver automations in UiPath work with Chrome, Firefox, and Edge, need the matching driver executable (ChromeDriver, geckodriver, msedgedriver) on the Path, and need no UiPath extension.
Selectors generated through WebDriver are the same as those from the UiPath extensions, except for window frames.
The Browser automation mode setting offers Browser Extension (default), WebDriver with GUI, WebDriver Headless, Chromium Automation, and Chromium Automation Headless.
WebDriver and Chromium modes open a new, isolated browser profile, so they cannot attach to a user's open browser and are unsuitable for attended automation.
Headless modes cannot perform hardware drag-and-drop or some screenshot operations; ChromeDriver must match the installed Chrome version.
9.1 Browser Automation with the WebDriver Protocol
Core Concept: By default, UiPath automates browsers through its browser extension. The exam description also asks you to "build a UI automation using Web Driver". The W3C WebDriver protocol lets the robot drive Chrome, Edge, or Firefox through a separate driver executable. It needs no UiPath extension, and it supports a headless mode in which no browser window is drawn at all.
How WebDriver Works in UiPath
WebDriver is a widely used protocol that exposes a REST API in an executable separate from the browser itself. Through it, a client can start browsers (headless or visible), click elements, type into fields, open tabs, read the DOM, and run JavaScript. In UiPath:
- Automations can use WebDriver with Google Chrome, Mozilla Firefox, and Microsoft Edge.
- No UiPath browser extension is required, but the matching driver executable is:
ChromeDriver.exe,geckodriver.exe, ormsedgedriver.exe. - Selectors generated through WebDriver are the same as those generated through the UiPath extensions, except for window frames.
- Each WebDriver run opens a new browser session that is independent of any browser the user already has open. When the browser closes, the driver process and its sessions end too.
Setting It Up
- Download the driver that matches the browser. ChromeDriver must match the installed Chrome version, and because Chrome updates itself often, the driver must be kept in step. geckodriver changes rarely; use the latest release.
- Put the driver in a folder, such as
C:\webdriver\Chrome. - Add that folder to the
Pathenvironment variable (user or system) through Windows' Edit the system environment variables dialog. - Choose the mode in Studio. In current UIAutomation packages (v26.10 and later), Use Application/Browser has a Browser automation mode property, and the project setting of the same name is in UI Automation Modern > Application/Browser. The activity-level value overrides the project default.
The Browser Automation Modes
UiPath describes three underlying methods exposed as five modes:
| Mode | Needs extension | Needs WebDriver binary | Visible window | Supported browsers | Attended use |
|---|---|---|---|---|---|
| Browser Extension (default) | Yes | No | Yes | Chrome, Edge, Firefox, Safari | Yes |
| WebDriver with GUI | No | Yes | Yes | Chrome, Edge, Firefox | No |
| WebDriver Headless | No | Yes | No | Chrome, Edge, Firefox | No |
| Chromium Automation | No | No | Yes | Chrome, Edge, other Chromium browsers | No |
| Chromium Automation Headless | No | No | No | Chrome, Edge, other Chromium browsers | No |
The two Chromium Automation modes use the Chrome DevTools Protocol directly, so no extension or driver download is needed. They are blocked when the DeveloperToolsAvailability Group Policy is set to 2, which disallows Developer Tools. In that environment, use the extension or WebDriver instead.
Why WebDriver and Chromium Modes Are Unattended-Only
WebDriver and Chromium Automation create a new user-data directory for every session. As a result:
- They cannot attach to a browser the user already has open, which makes them unsuitable for attended automation, where the robot works in the user's own browser.
- The session uses an isolated profile, so extensions, saved passwords, and session cookies from the user's normal profile are not available. Log in inside the automation.
- Incognito or private browsing works without extra configuration, unlike with the extension, where you must allow the extension in Incognito.
For unattended jobs these points are rarely a problem, and headless modes are attractive on servers and in CI/CD pipelines where no display exists.
Headless Limitations
Headless modes skip everything that needs a visible window or OS-level rendering:
- Hardware events such as a physical mouse drag-and-drop are not supported.
- Some screenshot operations do not work.
- Image and Computer Vision targeting have no rendered screen to analyze, so rely on selectors.
A practical pattern is to build and debug with WebDriver with GUI, where you can watch the page, and then switch the same Use Application/Browser activity to WebDriver Headless for production.
Choosing a Mode
| Scenario | Recommended mode |
|---|---|
| Standard desktop automation where the extension can be installed | Browser Extension |
| Attended automation in the user's already-open browser | Browser Extension |
| Extension cannot be installed, and the browser must be visible | WebDriver with GUI |
| Extension cannot be installed, and no display is available | WebDriver Headless |
| Firefox or Safari without the extension | WebDriver (with GUI or headless) |
| Chrome or Edge with the simplest setup | Chromium Automation |
| Unattended server or pipeline runs on Chrome or Edge | Chromium Automation Headless |
Warning
A WebDriver automation that suddenly fails after a Chrome update usually has a version mismatch between Chrome and ChromeDriver. Keep the driver in step with the browser, or use Chromium Automation, which has no separate binary to maintain.
An unattended job must automate a web portal on a server with no display, and security policy forbids installing browser extensions. Chrome is available, and the DeveloperToolsAvailability policy is set to 2. Which mode fits?
Browser Extension, because it is the default mode.
Chromium Automation Headless, because it needs no extension.
Hardware Events with a maximized window.
WebDriver Headless with a ChromeDriver version that matches the installed Chrome.
Why is WebDriver with GUI a poor choice for an attended automation that must work in the browser tab the user already has open?
WebDriver starts a new browser session with its own user-data directory and cannot connect to an already-open browser.
WebDriver supports only Firefox.
WebDriver cannot show a visible browser window.
WebDriver sessions are limited to one click per page.
A WebDriver-based automation that ran for months starts failing right after Chrome updates itself overnight. What is the most likely cause?
The selectors generated by WebDriver differ from extension selectors.
Headless mode was disabled by the update.
The installed ChromeDriver no longer matches the new Chrome version.
The UiPath extension for Chrome was removed.
Sections you finish are checked off in the contents.