Guide

Robot Framework vs Selenium: Pick the Syntax, Then Pick the Engine

Robot Framework and Selenium are not rivals on the web because they stack. Compare how each is authored, run, and repaired, then pick the engine underneath.

Dhaval Shreyas

CEO & Co-founder at Pie

13 min read Posted Sep 15, 2026

A Layer and an Engine, Not Two Rivals

Selenium is a browser automation engine, and Robot Framework is a keyword-driven test framework with no browser control of its own, so it borrows one. For web UI those two things stack rather than compete, and for most Robot Framework suites the engine underneath is Selenium.

They get pitted against each other because they surface in the same “how do I test my web app” search, not because they occupy the same slot. Robot Framework calls itself a generic open source automation framework, not a browser tool.

What Robot Framework and Selenium Each Actually Do

Robot Framework expresses tests as human-readable keywords across many domains. Selenium does one thing deeply, which is drive real browsers over a standard protocol.

Robot Framework Is a Python Layer With No Browser

Robot Framework was released as open source in 2008 at Nokia Networks, and the non-profit Robot Framework Foundation has held the copyright since 2016. It is written in Python and runs on Python, so every suite carries a Python dependency underneath a tabular syntax where a test reads as named steps such as Open Browser or Input Text.

• The job: Expresses tests as reusable keywords and drives whatever its libraries reach.
• The limit: No browser of its own. The ten bundled libraries cover files, processes, strings, and XML, and none of them touches one.
• How it gets a browser: SeleniumLibrary or the Playwright-based Browser library, plus others for APIs, databases, and mobile.
• Current release: Core 7.5, released 14 September 2026.

Selenium Is a Browser Engine and a W3C Standard

Selenium started in 2004 at ThoughtWorks, where Jason Huggins built the first version to test an internal expenses app. It became the default way to drive a browser from code, and its wire protocol was standardized as the W3C WebDriver specification, a Recommendation since 5 June 2018.

• What it drives: Browser-specific drivers such as ChromeDriver and geckodriver, which control Chrome, Firefox, Safari, Edge, and Internet Explorer.
• How you call it: Official client bindings in Java, Python, C#, Ruby, JavaScript, and Kotlin.
• Where it stops: No structure or reporting for a suite. Grid distributes runs and IDE records them, and the engine stays scoped to browsers.
• Current release: 4.48.0, August 2026.

Robot Framework Borrows an Engine, and You Pick Which One

Robot Framework has no browser engine, so it loads one, and there are two real options. SeleniumLibrary has been the default since the beginning and carries most of the installed base. The alternative, Browser, runs on Playwright, and it is what the community now recommends for a new suite.

How a Keyword Becomes a WebDriver Call

Robot Framework tests the web by loading SeleniumLibrary, which wraps Selenium’s Python bindings and exposes them as keywords. The project’s own README calls SeleniumLibrary a web testing library that uses the Selenium tool internally.

When a Click Element keyword runs, SeleniumLibrary resolves the locator and issues the same WebDriver call a Python driver.find_element(...).click() would issue. Same protocol, same driver, same result on screen. You are choosing how to write the test down, not a different way to control the browser.

What the Browser Library Changes

The Browser library swaps Selenium out for Playwright, and what it inherits maps onto what people complain about in SeleniumLibrary. Playwright waits for an element to be actionable before every action instead of asking you to script the wait, and it reaches into iframes and shadow DOM without the usual workarounds.

The speed claim attached to that swap has a number and no method behind it. In April 2022 a contributor on the Robot Framework forum reported “up to 50% reduction of test execution times after migration of SeleniumLibrary to Browser,” relaying what users were saying in the project’s Slack. Four years on, nobody has published the suite or the numbers. Directionally believable, and not a measurement.

The forum is consistent about something less exciting. A suite started today should start on Browser. SeleniumLibrary stays right for teams carrying an existing Grid, a device cloud contract, older browser targets, or years of custom keywords written against WebDriver.

What Engine Coupling Costs, in Both Directions

Borrowing an engine means inheriting its bad weeks. In February 2024 a SeleniumLibrary user opened a forum thread because a suite that ran in about 35 minutes jumped to roughly an hour and eight minutes with nothing changed on their side. The cause was Chrome 121, and the thread closed without a fix.

Browser is not the escape hatch from that. A February 2023 thread on that library reported v16 running measurably slower than v14, with Wait For Elements State “exactly 1 second longer in Browser v16” (damies13, 10 February 2023). The speed did not return until v17.2.0 in January 2024, eleven months of holding back the library people reach for because it is faster.

Which Engine to Start On, and What a Swap Costs

Adoption favors the incumbent by a wide margin. The swap itself is hand work.

A QA manager at a large retail organization told us the team was moving a whole Selenium and Cucumber suite over to Playwright by hand. Swapping the library under your keywords is that same job one layer up, and what you are weighing is the argument in Playwright vs Selenium, unchanged by the keyword layer on top.

Start a new suite on Browser. Keep SeleniumLibrary when your Grid, your browser matrix, or your existing keywords are load-bearing, and price the migration as engineering work.

Who Writes the Tests, and Who Has to Read Them?

The real decision is authorship. Robot Framework’s keyword syntax lets people who do not write code author and read tests, and raw Selenium expects a programming language from everyone who opens it. Match that to whoever will own the suite in eighteen months.

Robot Framework’s tabular, keyword-driven style reads close to structured English, which is why testers and analysts adopt it for acceptance testing. Reusable keywords cut duplication too. Define Login With Valid User once, call it from fifty tests, fix it in one place. Same trade as Cucumber vs Selenium.

That win has a ceiling, and it is a team-size ceiling. Reusable keywords only cut duplication if somebody is policing the keyword library, and on a growing team nobody is. Paul Ballard put it plainly on Ministry of Testing in April 2024.

Robot can be clean but it can also be chaos.

He put the turn at around five or six test writers, past which duplicated keywords accumulate faster than anyone reviews them. The readable syntax invited the extra authors in, and keyword sprawl is the bill.

Authoring and repairing are two different jobs, and the keyword layer only helps with the first. A business analyst can write Click Element id=checkout-submit and read it back a month later. When a developer renames that id, the analyst sees which line failed and has no way to repair it, because the fix lives in the locator.

Raw Selenium runs the other way. You get a real programming language, its debugger and its control flow, with nothing between your code and the browser. The cost is headcount, and an engineering leader who had used Selenium for years and rated it highly told us it takes a full-time engineer or two to really run.

Robot Framework wins on who can author. Selenium wins on who can repair, and repair is the job that keeps coming back.

Where Each One Reaches Beyond the Browser

Robot Framework covers far more than the browser because it swaps in libraries, and Selenium is scoped to browsers deliberately. One keyword syntax drives web, REST APIs through RequestsLibrary, databases, native mobile through AppiumLibrary, and desktop automation.

Look at the API row, because it cuts against us. If one syntax across web, API, and mobile is the requirement, only Robot Framework satisfies it. A Pie script can call an API to set up state for a flow, but API contract testing is not a job Pie does.

Robot Framework is wider because it borrows engines. Selenium is deeper because it is one.

Speed, Community, and the Real Learning Curve

Raw Selenium should be marginally quicker than Robot Framework driving Selenium, and Selenium has by far the larger community. One of those gaps is measurable. The other is too small to decide anything.

Speed

Through SeleniumLibrary, Robot Framework runs the same Selenium underneath, so the only difference is its own keyword-dispatch and logging layer, and neither project publishes a benchmark. Treat that edge as mechanical reasoning with no measurement behind it. The engine is the real lever, because moving to Playwright changes how the tool waits for the page, and waiting is where a browser test spends most of its clock.

Ecosystem and Learning Curve

Maturity splits along predictable lines.

• Selenium: Four years older than Robot Framework, and adopted on a different scale. Its Stack Overflow tags carry 157,304 questions against Robot Framework’s 6,813, and its GitHub repository has 34,454 stars against 11,862, all four counted on 3 September 2026.
• Robot Framework: A smaller but active ecosystem organized around installable libraries, with report and log HTML generated on every run. Its learning curve is low to start and steeper later, when custom logic pushes you into writing Python keywords anyway.

The smaller number is not a satisfaction number, and that is what the raw counts hide. In the Robot Framework Foundation’s 2026 community survey, 79% of respondents said they use it almost daily and 94% said they prefer it over other tools. Those are people who already chose it, so read it as retention and not market share.

Selenium wins the ecosystem outright. Neither win changes the economics of owning the suite.

Locator Maintenance Is the Bill Both of Them Send

Both tools locate elements the same way, and that is where automation budgets actually go. Id, name, XPath, and CSS are all coupled to a UI that keeps changing, so a keyword test and a coded test aimed at one fragile locator fail on the same day.

The syntax on top has nothing to do with why the test broke, which is the pattern across most Selenium alternatives as well. Moving between the two rewrites the test and never touches the reason it broke.

What happens next is the part comparison posts leave out. Jinoo, who co-founded Pie, has implemented end-to-end suites on every team he has been on, and his account of each release is that some of them go brittle and break.

You either fix it, spend the time to fix it, or you just comment it out and skip it.

Nobody writes that third option into the plan. Most teams reach for it anyway, and a skipped test is indistinguishable from a passing one on the dashboard.

The repair work that does get done carries a price. A 2024 industrial case study at IEEE ICST tracked five years of CI data on a million-line commercial project and found flaky tests eating at least 2.5% of productive developer time, split between investigating failures and repairing them. One team, one codebase, and a floor. Structural causes drive most of that, which is the argument behind the root causes of flaky tests.

What we saw on customer calls is less precise and far more common. On a March call I described it as an observation about the teams we talk to and not a measurement anybody instrumented: “Initially 90% of their time is spent on building new test cases.” A few months in, we saw the ratio invert, “90% of the test time is spent on maintaining these test cases.”

The middle rows are where Robot Framework and Selenium diverge, and every comparison spends its word count there. The bottom rows are where they are identical, and that is where your engineering hours go.

Choose Robot Framework, Selenium, or Neither

Pick on who owns the suite, and on how much of the week disappears into upkeep. Two of the three answers are the ones the internet argues about. The third is the one teams live in.

The first four rows are the argument people actually have, and the two frameworks split it three to two. Both open-source columns sit blank on the last two, because a framework cannot generate the suite nobody has written yet, and it cannot stop locators moving under the one you already own.

Robot Framework Pros and Cons

• Non-coders can author: Testers and analysts write and review tests without knowing Python or Java.
• One syntax, many surfaces: The same keyword style drives web, REST APIs, databases, and native mobile through separate libraries.
• Keyword sprawl is the cost: Past five or six test writers, duplicated keywords turn into a maintenance problem of their own.

Budget for a Python-capable engineer behind it. The custom logic always arrives eventually.

Selenium Pros and Cons

• Full language control: You get a real programming language, its debugger, its libraries, and its control flow with nothing in between.
• Deepest archive of solved problems: Two decades of adoption means someone has usually hit and answered your exact error already.
• Everyone who touches it codes: There is no built-in structure for keyword reuse or readable reporting until you build a runner around it.

Anyone who opens this suite has to read code. Decide now whether that is everyone you need.

When Neither One Is the Answer

Look, neither is the answer when the suite exists to confirm users can finish the flows that make you money, and the week goes into repairing locators instead of deciding what to test. Swapping keywords for code does not touch that. Neither does swapping Selenium for Playwright.

A QA lead running six testers across a set of microservice products told us the newer suites had moved off Selenium and onto Playwright and hit the same wall. The reason was that “our locators keep on changing,” and the scripts end up, in the lead’s words, sort of no use.

What Pie Binds a Test To Instead

Pie is an autonomous QA platform that lives in the third column of that table, and what it changes is what a test is bound to. Its agents explore the application, work out which flows matter, and write the suite, so nobody hand-codes a keyword or a locator to begin with. The keyword-versus-code argument is about how you write the locator down. Pie is about not having one to write.

• Discovery instead of authoring: The agents map the real flows through your app, rank them by what a break costs you, and generate the suite from that. Nothing is hand-written, so there is no locator inheritance later.
• Vision-based execution: Elements are found by what is rendered instead of by a path you keep current, and the self-healing model re-identifies them when a layout shifts or a label is renamed.
• One definition across surfaces: One behavior-based test runs against the web app and the native iOS and Android builds, collapsing a Robot Framework web suite and a separate AppiumLibrary suite into one.

None of this is an argument against owning a framework. What an autonomous platform does not hand you is programmatic control of a browser API in code, so if a driver capability is load-bearing, or if API contract testing is the main job, Robot Framework remains a good tool for exactly that.

Most teams keep the framework for the programmatic cases and run Pie alongside it on the change-prone journeys. Fi, the smart pet collar company, does that on its mobile releases, and validation that used to take two to three days now takes a few hours. We map the swap on the Pie versus Selenium comparison, including where it does not pay.

Two Choices, One Invoice

Robot Framework and Selenium are not two engines competing for one slot. For web UI, one usually runs inside the other, and what is left to decide is smaller than the argument around it. Work out who writes and reads the tests, then work out which library belongs underneath them.

Both decisions leave the same bill unpaid. Each tool binds a test to a locator, and a locator is a promise that the interface will not move. We built Pie for the version of that problem with no syntax answer and no engine answer, where the agents write the suite and keep it working against a screen that will not hold still.

Pick your syntax, pick your engine, and know that neither one was the line item costing you the week.

Dhaval Shreyas

CEO & Co-founder at Pie

13 years building mobile infrastructure at Square, Facebook, and Instacart. Now building the QA platform he wished existed the whole time. LinkedIn →