ChromeDriver: Session Not Created, Version Mismatch Fix

session not created: This version of ChromeDriver only supports Chrome version N means the ChromeDriver binary and the Chrome binary on the machine have different major versions. The second line of the error tells you both numbers. With Selenium 4.6 or later, the fix is usually to delete code and files: remove the hard-coded driver path and the old chromedriver on PATH, and let Selenium Manager pick the matching driver.

This page belongs to our Selenium screenshot guide. We reproduced the error in three version pairs, traced where the stale driver came from, and tested the fix in Python. Java code follows the same pattern; we list what we could not run.

Tested on 2026-10-18 in Docker (python:3.12-slim-bookworm, linux/amd64) with Python 3.12, selenium 4.51.0, Chrome for Testing 128.0.6613.119, 148.0.7778.97 and 155.0.8059.79, and Debian's Chromium 155.0.8059.79.

Reproducing the error

The script below pins a driver path and a browser path, the way most old tutorials did. We then paired drivers and browsers from different Chrome for Testing releases.

import sys
from selenium import webdriver
from selenium.webdriver.chrome.service import Service

chrome_path, driver_path = sys.argv[1], sys.argv[2]

opts = webdriver.ChromeOptions()
opts.add_argument("--headless=new")
opts.add_argument("--no-sandbox")
opts.binary_location = chrome_path

driver = webdriver.Chrome(options=opts, service=Service(driver_path))
try:
    driver.get("https://example.com")
    driver.save_screenshot("example.png")
finally:
    driver.quit()

Results from the run:

Two things to read from this. The check is on the major version only: a driver build .84 worked with browser build .79. And the error is symmetric: an older Chrome with a newer driver fails the same way. That second case shows up when a server pins Chrome with apt-mark hold while the driver comes from a newer download.

Where the stale driver comes from

Every mismatch we have seen has one of these sources. Check them in this order.

1. A path in code. Service("/usr/local/bin/chromedriver") or executable_path= in old code always wins. Search the codebase for chromedriver.
2. A binary on PATH. Run which -a chromedriver and chromedriver --version. Selenium checks PATH before it downloads anything.
3. A Docker layer. A Dockerfile that downloads a driver once is cached. When the base image later brings a newer Chrome, the old driver layer stays.
4. A wrapper library. webdriver-manager and similar packages keep their own caches and can lag behind Chrome.
5. A second Chrome. The driver matches Chrome A, but binary_location or the system default points to Chrome B. The error's "binary path" shows which one was used.

What Selenium Manager does with an old driver on PATH

We put ChromeDriver 128 first on PATH, removed the Service path from the code, and pointed the browser at Chrome 155. Selenium 4.51.0 printed this warning, used the old driver anyway, and failed:

The chromedriver version (128.0.6613.119) detected in PATH at /opt/128.0.6613.119/chromedriver-linux64/chromedriver
might not be compatible with the detected chrome version (155.0.8059.79); currently,
chromedriver 155.0.8059.84 is recommended for chrome 155.*, so it is advised to delete
the driver in PATH and retry

So the warning names the exact fix. Many logs bury it above the stack trace, so search for "recommended for chrome" in CI output.

The tested fix (Python)

With no driver on PATH and no Service path, Selenium Manager resolved a matching driver. This ran in the same container:

from selenium import webdriver

opts = webdriver.ChromeOptions()
opts.add_argument("--headless=new")
opts.add_argument("--no-sandbox")
opts.binary_location = "/usr/bin/chromium"

driver = webdriver.Chrome(options=opts)  # no Service path: Selenium Manager picks the driver
try:
    caps = driver.capabilities
    print("browser", caps["browserVersion"], "driver", caps["chrome"]["chromedriverVersion"].split(" ")[0])
    driver.get("https://example.com")
    driver.save_screenshot("example.png")
finally:
    driver.quit()

Output: browser 155.0.8059.79 driver 155.0.8059.84. Print both versions at start-up like this in production; it turns the next mismatch into a one-line log entry instead of a stack trace. --no-sandbox is there because the container runs as root; the DevToolsActivePort page explains that trade-off.

If your network blocks downloads at runtime, pin instead of resolving: install Chrome for Testing and ChromeDriver of the same version in the image (for example with npx @puppeteer/browsers install [email protected] and [email protected]), and pass both paths.

The same fix in Java

Selenium Java 4.6+ includes the same Selenium Manager. Remove System.setProperty("webdriver.chrome.driver", ...) and any ChromeDriverService built with a fixed path:

import org.openqa.selenium.OutputType;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

import java.nio.file.Files;
import java.nio.file.Path;

public class Shot {
    public static void main(String[] args) throws Exception {
        ChromeOptions options = new ChromeOptions();
        options.addArguments("--headless=new");
        ChromeDriver driver = new ChromeDriver(options); // Selenium Manager resolves the driver
        try {
            driver.get("https://example.com");
            byte[] png = driver.getScreenshotAs(OutputType.BYTES);
            Files.write(Path.of("example.png"), png);
        } finally {
            driver.quit();
        }
    }
}

We did not run the Java listing: the test machine had no JDK installed on the test date. The class and method names are from the Selenium Java API.

Symptom, cause, fix

The same screenshot without a driver

A screenshot API removes the driver and the browser from your machine, so there is nothing to keep in step. With the RenderScreenshot Python SDK:

import os
from renderscreenshot import Client, TakeOptions

client = Client(os.environ["RS_API_KEY"])
image = client.take(TakeOptions.url("https://example.com").full_page())
with open("example.png", "wb") as f:
    f.write(image)

The Java SDK has the same take and TakeOptions calls, shown end to end in the Java screenshot API guide. We did not call the live API for this page. If you only use Selenium to take screenshots, not to test flows, a free API key replaces this whole class of error.