This Version of ChromeDriver Only Supports Chrome Version [Fixed]

The Selenium error session not created: This version of ChromeDriver only supports Chrome version N means the chromedriver executable that Selenium started was built for a different major version of Chrome than the browser it tried to open. We fix it by letting Selenium Manager pick the driver, which is built into Selenium since version 4.6, and by removing every old chromedriver that our code or the PATH still points to.

The error appears most often after Chrome updates itself, because a driver downloaded by hand stays at the old version. It also appears when an outdated helper library, such as WebDriverManager before 5.4, downloads the wrong driver.

The following example starts Chrome with Selenium 4.51.0 without any driver path, so Selenium Manager detects the installed Chrome and downloads the matching chromedriver on the first run.

static WebDriver openChrome() {
    ChromeOptions options = new ChromeOptions();
    options.addArguments("--headless=new");
    return new ChromeDriver(options);       // Selenium Manager resolves chromedriver
}

Notice that the code has no System.setProperty(“webdriver.chrome.driver”, …) line. We go through the parts of the error message, the places where a stale driver comes from, Selenium Manager, pinning a Chrome version in CI, the manual fix for offline machines, and WebDriverManager.

1. Why ChromeDriver and Chrome Versions Must Match

When running a UI test with Selenium, Chrome and ChromeDriver must have the same major version. ChromeDriver 130 can drive Chrome 130 only, so a browser that updated to 141 rejects it, and a driver that is newer than the browser fails the same way. Selenium reports the mismatch as a SessionNotCreatedException, an unchecked exception, while it creates the ChromeDriver object.

We reproduced the error on JDK 25 and Selenium 4.51.0 by pointing the webdriver.chrome.driver property at ChromeDriver 130 while Chrome 141 was installed. The trace is trimmed after the first frame.

Exception in thread "main" org.openqa.selenium.SessionNotCreatedException: Could not start a new session. Response code 500. Message: session not created: This version of ChromeDriver only supports Chrome version 130
Current browser version is 141.0.7390.37 with binary path /opt/google/chrome/chrome
Host info: host: 'vm', ip: '127.0.0.1'
Build info: version: '4.51.0', revision: '35c5fab 35c5fab4a58fa5878edb255eb7747b04ca51a015'
System info: os.name: 'Linux', os.arch: 'amd64', os.version: '6.18.44-fc-v114', java.version: '25.0.4.1'
Driver info: org.openqa.selenium.chrome.ChromeDriver
	at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:115)

The message contains all the data needed for the diagnosis. The number after “only supports Chrome version” is the driver’s major version, “Current browser version” is the installed Chrome, and “Build info” shows the Selenium version. If the Selenium version is 4.6 or newer, Selenium Manager is available and the stale driver comes from our own setup.

For example, a team runs its checkout UI tests on developer laptops and on a CI agent. Chrome updates itself on a Tuesday night, and on Wednesday every test fails with “only supports Chrome version 140”, because someone committed chromedriver.exe to the repository two months earlier.

2. Where the Wrong ChromeDriver Comes From

Selenium decides which driver to start before it opens the browser. An explicit path has the highest priority, a chromedriver on the PATH comes next, and only when neither exists does Selenium Manager check the browser version and download the matching driver into ~/.cache/selenium.

Every path in the diagram except the last one can give Selenium a driver that no longer matches the browser. Each source of a stale driver has its own sign in the project and its own fix.

Source of the stale driver	How to recognize it	Fix
System.setProperty(“webdriver.chrome.driver”, …) in a test base class	A hard-coded path such as C:/drivers/chromedriver.exe	Delete the line
ChromeDriverService.Builder().usingDriverExecutable(…)	Driver file kept in the project or on a shared drive	Remove the call or point it at a current driver
A chromedriver on the PATH	which chromedriver or where chromedriver prints a path	Delete it, or set SE_SKIP_DRIVER_IN_PATH=true
WebDriverManager older than 5.4	Pom shows webdrivermanager 5.3.x or lower	Upgrade to 6.4.0 or remove it
Selenium older than 4.6	“Build info” shows 4.5 or lower	Upgrade selenium-java to 4.51.0

Since Chrome 115, Google publishes ChromeDriver only through the Chrome for Testing endpoints, and the old ChromeDriver downloads page stops at version 114. Older tools that read the previous download location never find a driver newer than 114, which is why the error with “version 114” was so common in 2023 and 2024.

3. Fixing the Error With Selenium Manager

Selenium Manager is a small command-line tool that ships inside every Selenium release since 4.6. The Java bindings call it when we create a ChromeDriver without a driver path, and it detects the installed Chrome, finds the matching driver version and caches the download. For the fix, we upgrade Selenium and remove the code that points to a driver file.

<dependency>
  <groupId>org.seleniumhq.selenium</groupId>
  <artifactId>selenium-java</artifactId>
  <version>4.51.0</version>
</dependency>

After that, we delete every System.setProperty(“webdriver.chrome.driver”, …) line and every WebDriverManager.chromedriver().setup() call that we no longer need. The first run downloads the driver, and later runs reuse the cached copy until Chrome moves to a new major version.

3.1. Removing a Stale Driver From the PATH

Selenium Manager uses a chromedriver found on the PATH before it downloads anything. On our test machine, the npm chromedriver package had put ChromeDriver 147 into a Node.js bin folder, and the test failed with “only supports Chrome version 147” although Selenium Manager was active. Selenium logged a warning first.

WARNING: The chromedriver version (147.0.7727.24) detected in PATH at /usr/local/bin/chromedriver might not be compatible with the detected chrome version (141.0.7390.37); currently, chromedriver 141.0.7390.122 is recommended for chrome 141.*, so it is advised to delete the driver in PATH and retry

We find such drivers with which -a chromedriver on Linux and macOS, or where chromedriver on Windows, and delete them. If a tool needs that driver, we tell Selenium Manager to ignore the PATH with an environment variable.

which -a chromedriver
export SE_SKIP_DRIVER_IN_PATH=true
mvn test

With the variable set, the same test passed, and Selenium Manager stored ChromeDriver 141.0.7390.122 under ~/.cache/selenium/chromedriver/linux64/141.0.7390.122/. The tool also prints its decisions when we run it with –debug, which helps on a CI agent where we cannot open the browser.

[DEBUG] Found chromedriver 147.0.7727.24 in PATH: /usr/local/bin/chromedriver
[DEBUG] chrome detected at /opt/google/chrome/chrome
[DEBUG] Detected browser: chrome 141.0.7390.37
[DEBUG] Required driver: chromedriver 141.0.7390.122

4. Pinning the Chrome Version in CI

A test suite that follows whatever Chrome the agent has installed changes behavior whenever the agent updates. Selenium Manager can also download a Chrome for Testing build, a Chrome version made for automation that does not update itself. We set the browser version on the options, and Selenium Manager fetches that Chrome and its matching driver.

ChromeOptions options = new ChromeOptions();
options.setBrowserVersion("139");
options.addArguments("--headless=new");
String pinned = options.getBrowserVersion();             // "139"

In our run, new ChromeDriver(options) with version 139 downloaded Chrome 139.0.7258.154 into ~/.cache/selenium/chrome and ChromeDriver 139.0.7258.154 next to it, while the installed Chrome stayed at 141. The value also accepts the labels stable, beta, dev and canary, and browser downloads for Chrome are supported since Selenium 4.11.

Pinning costs disk space and a download of more than 100 MB per version on a fresh agent, so we cache ~/.cache/selenium between CI runs. Selenium Manager deletes cached drivers and browsers that were not used for 30 days.

5. Matching the Driver by Hand

Some locked-down machines block downloads, so Selenium Manager cannot fetch anything. On such machines, we download the driver ourselves, keep it next to the browser version it belongs to, and give Selenium its path. We first check both versions.

/opt/google/chrome/chrome --version
~/.cache/selenium/chromedriver/linux64/141.0.7390.122/chromedriver --version

Chromium 141.0.7390.37
ChromeDriver 141.0.7390.122 (b477534e7e10d193e916cd4e2967c589383625b2-refs/branch-heads/7390@{#2667})

A Chromium build prints Chromium, as above, while Google Chrome prints Google Chrome before the version. On a standard Linux install, the browser command is google-chrome, and on Windows the version is shown on chrome://settings/help. The major numbers, 141 in our output, must be equal, and the build numbers after them can differ. We download the driver for our platform from the Chrome for Testing dashboard and set its location through the driver service.

static WebDriver openChromeWithDriver(Path driverFile) {
    ChromeDriverService service = new ChromeDriverService.Builder()
            .usingDriverExecutable(driverFile.toFile())
            .build();
    return new ChromeDriver(service, new ChromeOptions());
}

A driver set by path breaks again at the next Chrome update, so we use it only where Selenium Manager cannot run. Setting SE_OFFLINE=true also stops Selenium Manager from making network requests, so it uses what is already cached.

6. Using WebDriverManager

The WebDriverManager library by Boni Garcia solved driver management before Selenium Manager existed. Versions before 5.4 cannot read the Chrome for Testing endpoints, so they fall back to ChromeDriver 114 and cause the same error with any newer Chrome. If a project uses it, we upgrade to the current version.

<dependency>
  <groupId>io.github.bonigarcia</groupId>
  <artifactId>webdrivermanager</artifactId>
  <version>6.4.0</version>
  <scope>test</scope>
</dependency>

static WebDriver openChromeWithWdm() {
    WebDriverManager.chromedriver().setup();
    return new ChromeDriver();
}

Selenium Manager can replace WebDriverManager when we only need driver management. The library still makes sense for features that Selenium Manager lacks, such as browsers in Docker containers.

7. JUnit 5 Test Without a Driver Path

The following example is a JUnit test that opens a page and checks its title. The browser starts once in a @BeforeAll method and closes in @AfterAll, and Selenium Manager supplies the driver.

class RecipeSiteTest {

    static WebDriver browser;

    @BeforeAll
    static void startBrowser() {
        ChromeOptions options = new ChromeOptions();
        options.addArguments("--headless=new", "--window-size=1280,800");
        browser = new ChromeDriver(options);
    }

    @Test
    void homePageHasTitle() {
        browser.get("data:text/html,<title>Recipes</title>");
        Assertions.assertEquals("Recipes", browser.getTitle());
    }

    @AfterAll
    static void stopBrowser() {
        browser.quit();
    }
}

The old options.setHeadless(true) method no longer exists in current Selenium 4 releases, so we pass –headless=new as an argument. To see which driver a session uses, we read the chrome capability, which printed chromedriverVersion=141.0.7390.122 in our run.

8. ChromeDriver Version Error FAQs

The same mismatch appears with other browsers, cached drivers and remote grids, with small differences.

8.1. How do I check which ChromeDriver version my test uses?

Read the capabilities of the running session. The chrome capability contains chromedriverVersion, and getBrowserVersion() returns the Chrome version.

static String driverInfo(WebDriver driver) {
    Capabilities caps = ((HasCapabilities) driver).getCapabilities();
    return caps.getBrowserVersion() + " / " + caps.getCapability("chrome");
}

8.2. Does Selenium download Chrome if it is not installed?

Yes, since Selenium 4.11. When Chrome is missing, or when setBrowserVersion() asks for a version that is not installed, Selenium Manager downloads a Chrome for Testing build into ~/.cache/selenium. Set SE_AVOID_BROWSER_DOWNLOAD=true to turn that off.

8.3. Does the same error happen with Edge and Firefox?

Yes. Edge reports “This version of Microsoft Edge WebDriver only supports Microsoft Edge version N”, and the cause is the same mismatch with msedgedriver. Firefox’s geckodriver supports a range of Firefox versions, so it fails less often. Selenium Manager resolves drivers for all three browsers.

8.4. Why do I get the error on Selenium Grid but not on my laptop?

The driver runs on the Grid node, not on our machine. The node’s Chrome and driver must match, so we update the node image or the Selenium Docker images together, because each image tag contains a matching Chrome and driver pair.

9. Conclusion

The error This version of ChromeDriver only supports Chrome version N means the driver and the browser have different major versions. Chrome updates itself, so any driver fixed by path, kept on the PATH or downloaded by an old WebDriverManager becomes outdated at some Chrome update.

With Selenium 4.6 or newer, the fix is to remove those drivers and let Selenium Manager resolve the right one. In CI, setBrowserVersion() pins a Chrome for Testing build so test runs stay repeatable, and the manual download stays the fallback for machines without network access.

10. References

• Selenium Manager documentation
• Selenium, Driver Service Class
• ChromeDriver downloads
• Chrome for Testing availability
• WebDriverManager documentation

Happy Learning !!

Source Code on Github