Chrome updated overnight, and this morning every test fails before it starts:
SessionNotCreatedException: Message: session not created:
This version of ChromeDriver only supports Chrome version 138
Current browser version is 141.0.7390.55
For years this was a rite of passage. You downloaded a driver by hand, matched it to your browser, and did it again every few weeks when Chrome auto-updated.
Most of that is no longer necessary, and a lot of the advice you will find online predates the fix. So the useful question is not "where do I download the right driver" but "why is my setup not handling this for me".
What the error means
A driver is a separate program that sits between your test and the browser. ChromeDriver for Chrome, geckodriver for Firefox. If you have not seen why that matters, how Selenium WebDriver works covers the model.
Each driver build understands a specific range of browser versions. Chrome 141 speaks a protocol that a ChromeDriver built for 138 does not fully understand, so it refuses to start a session rather than behave unpredictably.
The message is precise and worth reading properly. It names both versions, so it always tells you exactly how far apart they are.
Modern Selenium already solves this
Since Selenium 4.6, Selenium ships Selenium Manager, which is built in and on by default. It detects your browser version, works out the matching driver, downloads it, and caches it. Since 4.11 it can also download the browser itself if one is missing.
You do not install it, import it, or configure it. It is part of Selenium.
So on a current setup, this is all you need:
WebDriver driver = new ChromeDriver();
const driver = await new Builder().forBrowser('chrome').build();
No driver path, no manual download, no version pinning. If a guide tells you to download ChromeDriver and set a system property, it was written before 4.6.
So why are you still seeing it?
Four reasons, and the fix differs for each.
1. Your Selenium is older than 4.6
The most common cause on an established project. Check what you actually have:
# Node
npm list selenium-webdriver
# Maven
mvn dependency:tree | grep selenium
If it is 4.5 or older, or any 3.x, upgrading is the real fix. Everything below is a workaround for staying old.
2. Something still points at a manual driver
Selenium Manager only steps in when a driver is not already specified. If your code or your environment names one, that one wins, and it is probably stale.
Look for a hardcoded path:
// Delete this. It overrides Selenium Manager.
System.setProperty("webdriver.chrome.driver", "/usr/local/bin/chromedriver");
Also check for an old chromedriver earlier on your PATH, and for a driver manager library like WebDriverManager that you no longer need.
3. No network access to fetch the driver
Selenium Manager downloads on first use. On a locked down CI runner or a corporate network with no route out, it cannot, and you fall back to whatever is on the machine.
Here, pinning deliberately is correct. Cache a known driver in the image and point at it on purpose, so the version is a decision rather than an accident.
4. The browser and driver come from different places
Common in Docker. The image ships one Chrome, the build installs a driver from somewhere else, and they drift apart on the next rebuild. Install both from the same source, or use an image that pairs them.
How to check in ten seconds
Compare the two versions the error already gave you:
google-chrome --version # or: chrome://version in the browser
chromedriver --version
If they disagree and you are on Selenium 4.6 or newer, the question is not "how do I download a driver". It is "what is stopping Selenium Manager from doing its job", which is one of the four above.
Why it hits everyone at once
Chrome updates itself quietly, so the failure looks like a change on your side even though nothing you did changed. This is exactly why manual driver management is a poor fit for a browser that updates every few weeks, and why the tooling moved to resolving it automatically.
If you take one thing from this: a suite that breaks every time a browser updates is a setup problem, not a fact of life.
Remember this
The error names both versions, so it always tells you the gap. Selenium 4.6 and newer resolve the driver for you and 4.11 can fetch the browser too, so a mismatch on a current setup means something is overriding that: an old Selenium, a hardcoded driver path or stale PATH entry, no network to download, or a browser and driver from different sources. Pin deliberately when you have no network, and upgrade rather than working around it everywhere else.
Related: NoSuchElementException and element not interactable, the errors you meet once the session actually starts.
Once the browser does open, the next question is whether your tests are checking anything. The graded practice answers it: your test runs against a working app, then against a copy with the behaviour broken on purpose, and tells you which behaviour it missed. No local setup, so no version mismatch either.
Reference: Selenium Manager.