Launching a browser is the first step in a Selenium test. In Selenium, this is done with browser-specific drivers such as ChromeDriver, FirefoxDriver, or EdgeDriver.
In this article, you will learn how to launch Chrome, Firefox, and Edge in Selenium using Java. You will also see how to use browser options for incognito and headless mode, create a reusable driver setup, run the launch flow with TestNG, and fix common browser launch errors.
How Selenium Launches a Browser
When you create a browser driver object in Selenium, Selenium starts a new browser session.
For example:
WebDriverManager.chromedriver().setup(); WebDriver driver = new ChromeDriver();
These lines do a few things:
- WebDriverManager resolves the required ChromeDriver for the installed Chrome browser.
- Selenium starts the browser through ChromeDriver.
- Selenium creates a WebDriver session.
- Your test can now send commands to the browser.
Once the browser session is active, Selenium can perform actions such as opening a URL, finding elements, clicking buttons, entering text, reading page titles, and closing the browser.
For example:
driver.get("https://www.browserstack.com");
driver.manage().window().maximize();
driver.quit();Here, driver.get() opens the page, maximize() changes the browser window size, and quit() closes the full browser session.
The important point is that Selenium does not directly control the browser from your test code. Your Java code talks to WebDriver, WebDriver communicates with the browser driver, and the browser driver controls the actual browser. This is why browser launch issues often come from driver setup, browser version, browser options, or the execution environment.
Prerequisites for Launching Browser in Selenium
Before writing the browser launch code, set up the basic Java project correctly. This tutorial uses Selenium, TestNG, and WebDriverManager, so your project needs Java, Selenium libraries, WebDriverManager, supported browsers, and a test framework if you want the code to run like a real test suite.
1. Add Selenium Dependency
For a Maven project, add the Selenium Java dependency in the pom.xml file:
<dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>4.44.0</version> </dependency>
At the time of writing, Maven Central lists selenium-java version 4.44.0.
This dependency gives access to WebDriver classes such as WebDriver, ChromeDriver, FirefoxDriver, EdgeDriver, and browser option classes such as ChromeOptions, FirefoxOptions, and EdgeOptions.
2. Add TestNG Dependency
Add TestNG if you want to run Selenium code as a proper test instead of using only a main() method:
<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>7.12.0</version> <scope>test</scope> </dependency>
At the time of writing, Maven Central lists TestNG version 7.12.0.
TestNG helps define setup, test, and cleanup steps using annotations such as @BeforeMethod, @Test, and @AfterMethod. This matters because every browser session should be closed after the test, even when the test fails.
3. WebDriverManager dependency
Add this after the TestNG dependency:
<dependency> <groupId>io.github.bonigarcia</groupId> <artifactId>webdrivermanager</artifactId> <version>6.3.4</version> </dependency>
WebDriverManager resolves the required browser driver before Selenium starts the browser session. In this tutorial, each browser launch example uses a setup line such as:
WebDriverManager.chromedriver().setup();
This makes driver setup explicit and easier to verify from the terminal output.
4. Understand Driver Management in Selenium
In older Selenium setups, testers had to download browser drivers manually, match the driver version with the browser version, and set the driver path in code.
Selenium 4 includes Selenium Manager, which can locate or download browser drivers in many standard setups. This is useful when you want Selenium to handle driver setup automatically.
This tutorial uses WebDriverManager instead, so the driver setup step is visible in every example. When you write:
WebDriverManager.chromedriver().setup(); WebDriver driver = new ChromeDriver();
WebDriverManager resolves the compatible ChromeDriver first. Then Selenium starts the Chrome browser session through the new ChromeDriver().
Both Selenium Manager and WebDriverManager solve driver setup problems. The important point is to use one approach consistently in the article and in the code screenshots.
How to Launch Chrome, Firefox, and Edge in Selenium
Selenium provides separate driver classes for different browsers. The browser-specific class starts the browser session, but the test code can still use the common WebDriver interface. This keeps the test code consistent across Chrome, Firefox, and Edge.
1. Launch Chrome Browser
Use ChromeDriver to launch Chrome in Selenium. In this example, WebDriverManager is used to set up the matching ChromeDriver before the browser session starts.
package com.selenium;
import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.Test;
import java.io.IOException;
public class LaunchChrome {
@Test
public void launchChromeBrowser() throws IOException {
WebDriverManager.chromedriver().setup();
WebDriver driver = new ChromeDriver();
try {
driver.get("https://www.browserstack.com");
System.out.println("Chrome - Page title: " + driver.getTitle());
pauseForInspection();
} finally {
driver.quit();
}
}
private void pauseForInspection() throws IOException {
if (Boolean.getBoolean("pause")) {
System.out.println("Paused for inspection. Press Enter to continue...");
System.in.read();
}
}
}
In this example, WebDriverManager.chromedriver().setup() resolves the compatible ChromeDriver for the installed Chrome browser. Then new ChromeDriver() starts a new Chrome browser session.
The driver.get() method opens the target URL, and driver.getTitle() prints the page title in the terminal. The optional pauseForInspection() method keeps the browser open during a local run when the test is started with -Dpause=true. This is useful when you want to capture a browser screenshot for documentation.
After the inspection step, driver.quit() closes the full browser session and releases browser-related resources.
2. Launch Firefox Browser
Use FirefoxDriver to launch Firefox in Selenium. In this example, WebDriverManager is used to set up GeckoDriver before starting the Firefox browser session.
package com.selenium;
import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.testng.annotations.Test;
import java.io.IOException;
public class LaunchFirefox {
@Test
public void launchFirefoxBrowser() throws IOException {
WebDriverManager.firefoxdriver().setup();
WebDriver driver = new FirefoxDriver();
try {
driver.get("https://www.browserstack.com");
System.out.println("Firefox - Page title: " + driver.getTitle());
pauseForInspection();
} finally {
driver.quit();
}
}
private void pauseForInspection() throws IOException {
if (Boolean.getBoolean("pause")) {
System.out.println("Paused for inspection. Press Enter to continue...");
System.in.read();
}
}
}
In this example, WebDriverManager.firefoxdriver().setup() resolves GeckoDriver for the installed Firefox browser. Then the new FirefoxDriver() starts a new Firefox browser session.
The test opens https://www.browserstack.com, prints the page title in the terminal, and pauses the browser only when the test is run with -Dpause=true. This pause is useful when capturing screenshots for documentation because it keeps the browser open until you press Enter.
3. Launch Edge Browser
Use EdgeDriver to launch Microsoft Edge in Selenium. In this example, WebDriverManager is used to set up the matching EdgeDriver before starting the Edge browser session.
package com.selenium;
import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.edge.EdgeDriver;
import org.testng.annotations.Test;
import java.io.IOException;
public class LaunchEdge {
@Test
public void launchEdgeBrowser() throws IOException {
WebDriverManager.edgedriver().setup();
WebDriver driver = new EdgeDriver();
try {
driver.get("https://www.browserstack.com");
System.out.println("Edge - Page title: " + driver.getTitle());
pauseForInspection();
} finally {
driver.quit();
}
}
private void pauseForInspection() throws IOException {
if (Boolean.getBoolean("pause")) {
System.out.println("Paused for inspection. Press Enter to continue...");
System.in.read();
}
}
}
In this example, WebDriverManager.edgedriver().setup() resolves EdgeDriver for the installed Microsoft Edge browser. Then new EdgeDriver() starts a new Edge browser session.
The test opens https://www.browserstack.com, prints the page title in the terminal, and pauses the browser only when the test is run with -Dpause=true. This pause helps when capturing browser screenshots because it keeps the browser open until you press Enter.
Note: Edge is Chromium-based, but Selenium still uses the EdgeDriver class for Edge browser sessions. The setup pattern remains the same as Chrome and Firefox. WebDriverManager resolves the required browser driver first, and Selenium starts the browser through the driver class.
How to Launch Browser with Options
Browser options let you change how the browser starts. You can use them to run the browser in incognito mode, headless mode, set a fixed window size, disable notifications, or pass browser-specific preferences.
This is useful when the same test needs to run in different environments. For example, a local run may need a visible browser, while a CI run may need headless mode.
1. Incognito Mode
Browser options let you control how the browser starts. For Chrome, use ChromeOptions to pass startup arguments such as –incognito.
package com.selenium;
import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.testng.annotations.Test;
import java.io.IOException;
public class LaunchChromeIncognito {
@Test
public void launchChromeInIncognitoMode() throws IOException {
WebDriverManager.chromedriver().setup();
ChromeOptions options = new ChromeOptions();
options.addArguments("--incognito");
WebDriver driver = new ChromeDriver(options);
try {
driver.get("https://www.browserstack.com");
System.out.println("Incognito Chrome - Page title: " + driver.getTitle());
pauseForInspection();
} finally {
driver.quit();
}
}
private void pauseForInspection() throws IOException {
if (Boolean.getBoolean("pause")) {
System.out.println("Paused for inspection. Press Enter to continue...");
System.in.read();
}
}
}
In this example, WebDriverManager.chromedriver().setup() resolves ChromeDriver before the browser starts. The ChromeOptions object adds the –incognito argument, so Chrome opens in Incognito mode.
The test opens https://www.browserstack.com, prints the page title in the terminal, and pauses only when the test is run with -Dpause=true. This helps when capturing screenshots because the browser remains open until you press Enter.
2. Headless Mode
Headless mode runs Chrome without opening a visible browser window. It is commonly used in CI pipelines, remote servers, and environments where tests need to run without a desktop UI.
package com.selenium;
import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.testng.annotations.Test;
public class LaunchChromeHeadless {
@Test
public void launchChromeInHeadlessMode() {
WebDriverManager.chromedriver().setup();
ChromeOptions options = new ChromeOptions();
options.addArguments("--headless=new");
options.addArguments("--window-size=1920,1080");
WebDriver driver = new ChromeDriver(options);
try {
driver.get("https://www.browserstack.com");
System.out.println("Headless Chrome - Page title: " + driver.getTitle());
} finally {
driver.quit();
}
}
}
In this example, WebDriverManager.chromedriver().setup() resolves ChromeDriver before the browser session starts. The ChromeOptions object adds the –headless=new argument, so Chrome runs without opening a visible window.
The –-window-size=1920,1080 argument is important in headless mode. Without a fixed window size, Chrome may use a smaller default viewport, which can change responsive layouts and affect element visibility.
3. Window Size and Browser Preferences
You can also launch Chrome with a fixed window size and selected browser preferences. This helps keep test behavior more consistent across local machines, CI systems, and different screen resolutions.
In this example, ChromeOptions is used to set the browser window size and disable browser notifications.
package com.selenium;
import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.testng.annotations.Test;
import java.io.IOException;
public class LaunchChromeWithPreferences {
@Test
public void launchChromeWithPreferences() throws IOException {
WebDriverManager.chromedriver().setup();
ChromeOptions options = new ChromeOptions();
options.addArguments("--window-size=1366,768");
options.addArguments("--disable-notifications");
WebDriver driver = new ChromeDriver(options);
try {
driver.get("https://www.browserstack.com");
System.out.println("Chrome with Preferences - Page title: " + driver.getTitle());
pauseForInspection();
} finally {
driver.quit();
}
}
private void pauseForInspection() throws IOException {
if (Boolean.getBoolean("pause")) {
System.out.println("Paused for inspection. Press Enter to continue...");
System.in.read();
}
}
}
In this example, WebDriverManager.chromedriver().setup() resolves ChromeDriver before the browser session starts. The ChromeOptions object passes two startup arguments to Chrome.
The –window-size=1366,768 argument launches Chrome with a fixed viewport size. This is useful when you want consistent layout behavior during test runs. The –disable-notifications argument prevents browser notification prompts from interrupting the test flow.
How to Build a Reusable Browser Setup
The previous examples are useful for learning, but real test suites should not create browser drivers inside every test class. A reusable setup keeps browser creation in one place and makes it easier to run the same tests on Chrome, Firefox, or Edge.
1. Use a Config File
Store the browser name and application URL in a properties file instead of hardcoding them in the test.
browser=chrome url=https://www.browserstack.com
This lets you change the browser or test URL without editing the test class. For example, the same test can run on Chrome locally and Firefox in CI by changing only the config value.
2. Create a Driver Factory
A driver factory creates the correct browser driver based on the browser name from the config file.
import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.edge.EdgeDriver;
public class DriverFactory {
public static WebDriver createDriver(String browserName) {
if (browserName == null || browserName.trim().isEmpty()) {
throw new IllegalArgumentException("Browser name cannot be empty");
}
switch (browserName.trim().toLowerCase()) {
case "chrome":
WebDriverManager.chromedriver().setup();
return new ChromeDriver();
case "firefox":
WebDriverManager.firefoxdriver().setup();
return new FirefoxDriver();
case "edge":
WebDriverManager.edgedriver().setup();
return new EdgeDriver();
default:
throw new IllegalArgumentException("Unsupported browser: " + browserName);
}
}
}This approach is better than writing browser setup logic inside every test class. Each case first resolves the required browser driver through WebDriverManager and then creates the browser session. It also fails clearly when the browser value is missing, empty, or unsupported.
3. Add a Config Reader
To connect the properties file with the test, add a small config reader class:
import java.io.FileInputStream;
import java.io.IOException;
import java.util.Properties;
public class ConfigReader {
private static final Properties properties = new Properties();
static {
try (FileInputStream file = new FileInputStream("src/test/resources/config.properties")) {
properties.load(file);
} catch (IOException e) {
throw new RuntimeException("Unable to load config.properties file", e);
}
}
public static String get(String key) {
String value = properties.getProperty(key);
if (value == null || value.trim().isEmpty()) {
throw new IllegalArgumentException("Missing config value for key: " + key);
}
return value.trim();
}
}This keeps config loading separate from browser creation. The driver factory creates the browser, while the config reader only reads values from the properties file.
4. Add TestNG Setup and Teardown
Use TestNG annotations to launch the browser before each test and close it after each test.
import org.openqa.selenium.WebDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;
public class BrowserLaunchTest {
WebDriver driver;
@BeforeMethod
public void setUp() {
String browser = ConfigReader.get("browser");
driver = DriverFactory.createDriver(browser);
driver.manage().window().maximize();
}
@Test
public void verifyPageTitle() {
String url = ConfigReader.get("url");
driver.get(url);
Assert.assertFalse(driver.getTitle().isEmpty(), "Page title should not be empty");
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}This version now uses the config file instead of hardcoding “chrome” inside the test. The test class only decides what to test, while browser selection and URL values come from config.
Common Errors When Launching Browser in Selenium
Browser launch failures usually come from driver setup, browser installation, browser options, or the machine where the test is running. The error message often tells you where to look first.
1. SessionNotCreatedException
SessionNotCreatedException usually means Selenium could not create a new browser session.
Common causes include:
- Browser and driver mismatch: The browser version is not compatible with the driver version.
- Unsupported browser option: A launch argument or capability is not valid for that browser.
- Browser startup failure: The browser is installed, but it cannot start in the current environment.
- Old Selenium version: The Selenium client is outdated and does not support the installed browser version properly.
Example error:
SessionNotCreatedException: Could not start a new session
How to fix it:
- Update Selenium to a recent Selenium 4 version.
- Let WebDriverManager resolve the browser driver before the Selenium session starts.
- Remove unnecessary browser options and test again with a basic driver launch.
- Check whether the browser opens normally outside Selenium.
2. NoSuchDriverException
NoSuchDriverException means Selenium could not find or obtain the required browser driver.
Example error:
NoSuchDriverException: Unable to obtain driver for chrome
This can happen when the driver manager cannot download or locate the required browser driver.
Common causes include:
- No internet access: WebDriverManager cannot download or resolve the required driver.
- Corporate proxy or firewall: The driver download is blocked.
- Browser is not installed: Selenium cannot detect the browser binary.
- Restricted CI environment: The runner does not allow driver download or file execution.
How to fix it:
- Confirm that the browser is installed on the machine.
- Check whether the test machine has internet access.
- Configure proxy settings if your network requires them.
- In locked-down systems, download the driver manually and provide the driver path through build or environment configuration.
3. Browser Opens and Closes Immediately
This usually happens when the script finishes execution right after launching the browser.
Example:
WebDriverManager.chromedriver().setup();
WebDriver driver = new ChromeDriver();
driver.get("https://www.browserstack.com");
driver.quit();The browser may open and close so quickly that it looks like Selenium failed.
How to fix it:
- Add a real test action or assertion before closing the browser.
- Use TestNG or JUnit so setup, test, and teardown are clearly separated.
- Do not remove driver.quit() just to keep the browser open. That can leave browser processes running.
- For debugging, add a breakpoint or use temporary waits only during local investigation.
A better test structure looks like this:
@Test
public void verifyPageTitle() {
driver.get("https://www.browserstack.com");
Assert.assertTrue(driver.getTitle().length() > 0);
}4. Browser Fails in CI
A browser may launch correctly on a local machine but fail in CI. This usually happens because CI machines are more restricted than local systems.
Common causes include:
- No display server: The CI machine cannot open a visible browser window.
- Missing browser installation: Chrome, Firefox, or Edge is not installed on the runner.
- Small default viewport: Headless mode starts with a small window size.
- Linux sandbox issues: Some containers block browser sandbox behavior.
- Limited memory: The browser process crashes before the session starts.
How to fix it:
- Use headless mode for CI runs.
- Set a fixed window size.
- Confirm that the required browser is installed in the CI image.
- Keep browser launch options minimal.
- Check browser, driver, and Selenium logs instead of only reading the test failure.
Example CI-friendly Chrome setup:
WebDriverManager.chromedriver().setup();
ChromeOptions options = new ChromeOptions();
options.addArguments("--headless=new");
options.addArguments("--window-size=1920,1080");
WebDriver driver = new ChromeDriver(options);Use extra Chrome flags such as –no-sandbox or –disable-dev-shm-usage only when the CI environment needs them. Do not add them by default to every test setup.
Best Practices for Launching Browser in Selenium
A browser launch method should be simple, reusable, and easy to debug. If browser setup becomes too complex, failures become harder to trace because the issue may be in the browser, driver, options, config, or test environment.
Use these practices to keep browser launch stable across local and CI runs:
- Use one driver management approach consistently: Selenium 4 includes Selenium Manager, and WebDriverManager is also commonly used in Java projects. Avoid mixing Selenium Manager, WebDriverManager, and manual driver paths in the same project unless there is a clear reason.
- Keep browser setup separate from test logic: Create browsers in a setup class, base test, or driver factory. Test methods should focus on test actions and assertions, not driver creation.
- Always close the browser session: Use driver.quit() in teardown. This closes the full WebDriver session and prevents leftover browser processes from affecting later tests.
- Use browser options only when needed: Add options such as headless mode, incognito mode, window size, or disabled notifications for a clear reason. Too many launch flags can hide real browser behavior.
- Set a fixed window size for headless runs: Headless browsers can start with a small default viewport. This can cause responsive layout changes, hidden elements, and false failures.
- Keep browser selection configurable: Store the browser name in config, build parameters, or CI variables. This makes it easier to run the same tests across Chrome, Firefox, and Edge.
- Fail fast for unsupported browsers: If the config says safari but your framework supports only Chrome, Firefox, and Edge, throw a clear exception. Do not silently fall back to Chrome.
- Avoid using waits to fix launch issues: Implicit waits or sleep statements do not solve browser startup problems. Fix the actual issue, such as missing browser installation, invalid options, driver resolution, or CI restrictions.
- Check logs when launch fails: Browser launch errors often contain useful details. Review Selenium logs, browser driver logs, and CI runner logs before changing the code.
- Test the simplest launch first: When debugging, start with only the WebDriverManager setup line and the basic browser driver. Add browser options back one by one to identify which setting causes the failure.
Conclusion
Launching a browser in Selenium is simple when the setup is clean. Chrome, Firefox, and Edge can be started with their browser-specific driver classes, while options such as incognito mode, headless mode, and fixed window size help control how the browser opens during local or CI runs.
For real test suites, avoid placing browser setup inside every test. Use a reusable driver factory, keep browser selection configurable, add TestNG setup and teardown, and close every session with driver.quit(). If browser launch fails, start with a basic driver launch first, then check driver resolution, browser installation, browser options, and CI environment limits.
