Browser Library vs Selenium in Robot Framework

The State of Browser Testing in Robot Framework

Robot Framework has long been a cornerstone of acceptance-test-driven development. For years, SeleniumLibrary was the de facto standard for web UI testing — a stable, battle-tested bridge to Selenium WebDriver. But the testing ecosystem has fundamentally shifted.

Playwright, Microsoft's browser automation framework, entered the scene and changed what developers expect from a browser automation tool: native async support, auto-waiting, multi-browser parallelism, network mocking, and built-in tracing. The Robot Framework community responded by building Browser Library — a first-class RF library powered by Playwright under the hood.

How SeleniumLibrary Works

SeleniumLibrary wraps Selenium WebDriver — the W3C-standardised protocol that talks to browser-specific drivers (chromedriver, geckodriver, etc.). Commands flow from your test → RF keyword → SeleniumLibrary → WebDriver JSON Wire Protocol → browser.

*** Settings ***
Library    SeleniumLibrary

*** Test Cases ***
Login Should Succeed
    Open Browser    https://example.com/login    chrome
    Input Text       id=username    admin
    Input Text       id=password    secret
    Click Button     id=submit
    Wait Until Page Contains    Dashboard
    Close Browser

SeleniumLibrary Characteristics

The Selenium model is inherently synchronous and sequential. Each command is sent over HTTP to the driver, which executes it and returns. This round-trip latency adds up quickly. More critically, Selenium has no built-in awareness of when the browser is truly "ready" — you must manually sprinkle Wait Until keywords everywhere.

Enter Browser Library (Playwright-Powered)

Browser Library was created by Mikko Korpela and the Robot Framework community to bring Playwright's capabilities into the RF ecosystem. Unlike SeleniumLibrary, it communicates with a persistent Node.js Playwright server via gRPC — enabling true async execution, native event handling, and deep browser integration.

*** Settings ***
Library    Browser

*** Test Cases ***
Login Should Succeed
    New Browser    chromium    headless=False
    New Page       https://example.com/login
    Fill Text      id=username    admin
    Fill Text      id=password    secret
    Click          id=submit
    Wait For Elements State    text=Dashboard    visible
    Close Browser

On the surface it looks similar — but under the hood the mechanics are radically different. Playwright auto-waits for elements to be actionable before interacting. No more Sleep 2s before clicking a button.

Head-to-Head Comparison

Browser Library's Winning Advantages

Auto-Waiting in Practice

This is perhaps the single most impactful difference. In SeleniumLibrary, a typical login flow might look like this — peppered with sleeps and explicit waits:

# SeleniumLibrary — manual waits everywhere
Click Button    id=submit
Sleep           2s
Wait Until Element Is Visible    id=dashboard    timeout=10s
Wait Until Element Is Enabled    id=continue-btn

With Browser Library, the same logic becomes:

# Browser Library — auto-wait baked in
Click    id=submit
Wait For Elements State    id=dashboard    visible

Playwright checks that an element exists, is visible, is not covered by another element, and is not animating before performing any action. This makes tests dramatically more stable.

Network Mocking

Browser Library exposes Playwright's routing API, allowing you to intercept and stub HTTP requests directly in your test suite — no proxy servers, no WireMock, no Mockoon required:

*** Test Cases ***
Mock API Response
    New Page    https://myapp.com
    ${mock_data}=    Create Dictionary    status=success    user=TestUser
    Mock With Dummy    https://api.myapp.com/profile    200    ${mock_data}
    Reload
    Get Text    id=username-display    ==    TestUser

Parallel Execution: Browser Contexts

Browser Library introduces the concept of browser contexts — isolated browser instances within the same browser process, each with their own cookies, localStorage, and authentication state. This enables lightning-fast parallel tests without the overhead of spawning entirely new browser processes:

*** Test Cases ***
Test Multiple Users Simultaneously
    New Browser    chromium
    # Context 1 — User A
    New Context
    New Page    https://app.com
    Login As    user_a@example.com
    # Context 2 — User B (completely isolated)
    New Context
    New Page    https://app.com
    Login As    user_b@example.com

Migrating from SeleniumLibrary

The migration is not a direct keyword-for-keyword swap — Browser Library has a different philosophy and vocabulary. The most important mindset shift: stop thinking in terms of finding elements and start thinking in terms of actions on selectors.

Installation

pip install robotframework-browser
rfbrowser init          # Downloads Playwright + bundled browsers

Keyword Mapping Reference

When to Still Use SeleniumLibrary

Browser Library is the superior default — but SeleniumLibrary still has legitimate use cases:

• You need to test on real Safari on macOS/iOS (WebKit emulation ≠ real Safari)
• Your app requires a specific browser version that Playwright doesn't support
• You have a massive legacy SeleniumLibrary codebase with no budget to migrate
• Your organisation mandates Selenium Grid / Sauce Labs / BrowserStack with Selenium protocol

Outside of these scenarios, the productivity, reliability, and feature advantages of Browser Library make it the clear winner for any new project.