Next-Gen App & Browser Testing Cloud

Trusted by 2 Mn+ QAs & Devs to accelerate their release cycles

What Is the Base Class of WebDriver in Selenium?

In Selenium, WebDriver is an interface, not a class. The base class that implements the WebDriver interface is RemoteWebDriver, and every browser-specific driver — ChromeDriver, FirefoxDriver, EdgeDriver, and SafariDriver — extends RemoteWebDriver. That single inheritance chain is why you can write WebDriver driver = new ChromeDriver() and have the exact same code run on any browser.

Below we walk through the full Selenium WebDriver hierarchy, clear up the interface-versus-class confusion, list the methods the base class gives you, and show the Java code that ties it all together.

What Is WebDriver in Selenium

WebDriver is the programming interface at the heart of Selenium automation. It is the contract that defines what a browser driver can do — open a URL, find an element, read the title, manage cookies, navigate, and switch context — without saying how any particular browser does it. When you import org.openqa.selenium.WebDriver, you are importing a Java interface, not a concrete class you can instantiate on its own.

Because WebDriver is just a set of method signatures, you always need a real implementation behind it at runtime. That implementation is supplied by a browser driver — most commonly ChromeDriver — which ultimately traces back to one shared base class. Understanding which class that is removes most of the confusion testers have around the WebDriver type.

Is WebDriver a Class or an Interface

This is the single most common point of confusion, so let us settle it clearly: WebDriver is an interface. You cannot write new WebDriver() — the compiler rejects it because interfaces have no constructor and no method bodies. An interface only declares behavior; a class provides it.

Interface — a pure contract. WebDriver lists methods like get(), findElement(), and quit() but implements none of them.
Class — the concrete code. RemoteWebDriver implements every WebDriver method with working logic that talks to the browser over the WebDriver protocol.
Base class — in Selenium, the shared implementing class that browser drivers extend. That class is RemoteWebDriver.

So when the question asks for the "base class of WebDriver," the precise answer is: WebDriver itself is an interface, and RemoteWebDriver is the base class that implements it and is extended by every browser driver.

The Selenium Class Hierarchy (RemoteWebDriver as Base Class)

The cleanest way to remember the answer is to picture the inheritance chain from the top interface down to the concrete browser driver you instantiate:

SearchContext            (super-interface: findElement, findElements)
        |
   WebDriver             (interface: get, getTitle, manage, navigate, switchTo, quit)
        |
RemoteWebDriver          (BASE CLASS: implements WebDriver)
        |
   +----+----+----------+-----------+
   |         |          |           |
ChromeDriver FirefoxDriver EdgeDriver SafariDriver  (concrete browser drivers)

Reading it top to bottom: SearchContext is the super-interface that declares element-finding methods — and it is shared by both WebDriver and WebElement, which is why you can call findElement() on the driver and on an element. WebDriver extends SearchContext and adds browser-control methods. RemoteWebDriver is the first real class — it implements WebDriver with concrete code. Finally, each browser-specific driver extends RemoteWebDriver, overriding only the small parts unique to that browser. For a fuller walkthrough of every layer, see the Selenium 4 WebDriver hierarchy.

That is exactly why the polymorphic declaration below works. The reference type is the WebDriver interface; the actual object is a ChromeDriver, which is a RemoteWebDriver, which implements WebDriver:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class HierarchyDemo {
    public static void main(String[] args) {
        // Reference type = WebDriver interface, object = ChromeDriver
        WebDriver driver = new ChromeDriver();

        driver.get("https://www.lambdatest.com");
        System.out.println("Title: " + driver.getTitle());

        // ChromeDriver IS-A RemoteWebDriver IS-A (implements) WebDriver
        System.out.println(driver instanceof org.openqa.selenium.remote.RemoteWebDriver); // true

        driver.quit();
    }
}

Because ChromeDriver inherits its implementation from RemoteWebDriver, switching browsers is a one-line change. Replace new ChromeDriver() with new FirefoxDriver() or new EdgeDriver() and every other line of the test stays the same — the power of coding to the interface while leaning on the common base class.

Methods Provided by the Base Class

RemoteWebDriver supplies the working implementation for every method declared on the WebDriver and SearchContext interfaces. These are the methods you call on the driver object every day:

get(String url) — loads a web page in the current browser window.
findElement(By by) / findElements(By by) — locate one element or a list of elements (inherited from SearchContext).
getTitle() / getCurrentUrl() / getPageSource() — read the current page's title, URL, and HTML.
manage() — returns an Options object to handle cookies, timeouts, and the window size.
navigate() — returns a Navigation object for to(), back(), forward(), and refresh().
switchTo() — returns a TargetLocator to switch into frames, windows, or alerts.
getWindowHandle() / getWindowHandles() — track the current and all open browser windows.
close() / quit() — close the active window or end the whole session and kill the driver.

RemoteWebDriver also implements several other interfaces — JavascriptExecutor, TakesScreenshot, and HasCapabilities — which is why you can cast the same driver object to run JavaScript or capture screenshots without instantiating anything new.

WebDriver driver = new ChromeDriver();

// All of these are implemented in the RemoteWebDriver base class:
driver.get("https://www.lambdatest.com");
driver.manage().window().maximize();
driver.manage().timeouts().implicitlyWait(java.time.Duration.ofSeconds(10));
driver.findElement(org.openqa.selenium.By.id("search")).sendKeys("Selenium");
driver.navigate().refresh();

// RemoteWebDriver also implements JavascriptExecutor:
((org.openqa.selenium.JavascriptExecutor) driver)
    .executeScript("return document.title;");

driver.quit();

Common Mistakes and Troubleshooting

Calling new WebDriver() — this never compiles. WebDriver is an interface; instantiate a concrete driver like new ChromeDriver() and assign it to a WebDriver reference.
Confusing RemoteWebDriver with a custom BaseClass — RemoteWebDriver is the Selenium library class. A BaseClass or BaseTest is your own class holding setup and teardown; they are different things.
Declaring the variable as ChromeDriver — typing ChromeDriver driver = new ChromeDriver() locks the test to Chrome. Declare it as WebDriver to keep the code browser-agnostic.
Expecting browser-only methods on WebDriver — methods such as executeScript() live on JavascriptExecutor, not WebDriver. Cast the driver before calling them.
Mismatched driver and browser versions — a ChromeDriver built for an older Chrome throws SessionNotCreatedException. Keep the driver binary aligned with the installed browser, or run on a managed cloud grid.

Cross-Browser Execution With the Cloud

The base class is not just an academic detail — it is what makes scalable cross-browser testing possible. Because every browser driver extends RemoteWebDriver, you can point that same RemoteWebDriver at a remote grid URL and run an identical test on a browser that is not even installed on your machine. This is the foundation of cloud-based Selenium execution. For a deeper look at how it differs from the plain WebDriver interface, read Selenium RemoteWebDriver.

With TestMu AI, you instantiate a RemoteWebDriver against the cloud hub and run the exact same Selenium code across 3000+ real browser and operating-system combinations. The hierarchy you just learned is the reason it works: the test is written against the WebDriver interface, and RemoteWebDriver routes those calls to whichever remote browser you request. Pair it with cross browser testing and automation testing to validate every environment your users run.

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import java.net.URL;

ChromeOptions options = new ChromeOptions();
options.setCapability("browserName", "Chrome");
options.setCapability("platformName", "Windows 11");

// RemoteWebDriver is the base class that runs your test on the cloud grid
WebDriver driver = new RemoteWebDriver(
    new URL("https://USERNAME:[email protected]/wd/hub"), options);

driver.get("https://www.lambdatest.com");
System.out.println("Title on cloud browser: " + driver.getTitle());
driver.quit();

Notice that you instantiate RemoteWebDriver directly here — the same base class that ChromeDriver extends locally. Only the constructor arguments change, proving how central this one class is to the whole framework.

Conclusion

To answer the question directly: in Selenium, WebDriver is an interface, and RemoteWebDriver is the base class that implements it. Every browser-specific driver — ChromeDriver, FirefoxDriver, EdgeDriver, SafariDriver — extends RemoteWebDriver, inheriting a shared set of methods like get(), findElement(), manage(), navigate(), and switchTo(). Code to the WebDriver interface, lean on the RemoteWebDriver base class, and your tests run unchanged on any browser — local or in the cloud.

Frequently Asked Questions

Is WebDriver a class or an interface in Selenium?

WebDriver is an interface, not a class. It declares the methods a browser driver must provide, such as get(), findElement(), and quit(), but contains no implementation. The class that implements those methods is RemoteWebDriver, which all browser-specific drivers extend.

What is the base class of WebDriver in Selenium?

RemoteWebDriver is the base class that implements the WebDriver interface. ChromeDriver, FirefoxDriver, EdgeDriver, and SafariDriver all extend RemoteWebDriver, inheriting its core methods and overriding only what each browser needs, which is why the same WebDriver code runs everywhere.

Why do we write WebDriver driver = new ChromeDriver()?

We code to the WebDriver interface rather than the ChromeDriver class so the test stays browser-agnostic. The reference type is WebDriver, while the object is a ChromeDriver. Swapping ChromeDriver for FirefoxDriver changes one line and the rest of the test is untouched.

What is the super-interface of WebDriver?

SearchContext is the super-interface of WebDriver. It declares the findElement() and findElements() methods. WebDriver extends SearchContext and adds browser-control methods such as get(), getTitle(), manage(), navigate(), and switchTo().

Is RemoteWebDriver the same as the BaseClass in a test framework?

No. RemoteWebDriver is the Selenium library class that implements WebDriver. A BaseClass or BaseTest is a custom class testers write to hold shared setup, teardown, and utility methods so test classes can inherit them. The two are unrelated concepts.

What is the difference between WebDriver and RemoteWebDriver?

WebDriver is the interface that declares the methods; RemoteWebDriver is the class that implements them. RemoteWebDriver also handles communication with a remote or local browser over the WebDriver protocol, so it is what actually runs your commands. ChromeDriver and the other browser drivers extend RemoteWebDriver.

What are the different types of drivers available in WebDriver?

The main browser drivers are ChromeDriver, FirefoxDriver (GeckoDriver), EdgeDriver, SafariDriver, and InternetExplorerDriver, plus RemoteWebDriver for grids. Each one extends RemoteWebDriver and controls its own browser. HtmlUnitDriver, a lightweight headless driver, is also available for fast, GUI-less runs.