How to Use OperaDriver with Selenium for Browser Automation
Set up OperaDriver with Selenium in Python, choose a compatible driver release, and troubleshoot common session errors.
To automate Chromium-based Opera with Selenium, start OperaDriver as a service and connect to it with Selenium’s RemoteWebDriver. Configure ChromeOptions with the path to the Opera executable when automatic browser detection is unreliable. Choose an OperaDriver release whose release entry names the Opera Stable version installed on your machine: the driver build number is not necessarily the browser version it targets.
This guide covers desktop Python setup, browser discovery and attachment options, version selection, troubleshooting, and an optional Android/Appium path. The code uses Selenium 4’s service pattern; check the installed Selenium binding’s API if you use a different version.
1. Understand which OperaDriver you need
OperaChromiumDriver is Opera’s ChromeDriver-derived WebDriver implementation for automating Chromium-based Opera on desktop and Android. Its project README says no extra setup is needed for Chromium-based Opera starting with version 26, but that statement does not guarantee compatibility between every modern Opera and driver build. For Presto-based Opera, the project points to the separate OperaPrestoDriver project.
WebDriver lets a script interact with a browser as a user would: open pages, click links, enter text, and submit forms. The examples here focus on desktop Opera with Python and Selenium.
2. Install Selenium and obtain OperaDriver
- Install a Selenium Python binding in the environment that will run your script:
python -m pip install selenium - Find the OperaChromiumDriver release that targets your installed Opera Stable version on the official releases page. Read the release description and download the binary for your operating system.
- Install or locate the Opera desktop browser. Record the full path to its executable and to the downloaded OperaDriver binary.
- Make sure the driver file is executable on Unix-like systems if needed, and that your account can run it.
For example, the paths might look like /usr/bin/operadriver and /usr/bin/opera on Linux, or point into application folders on macOS or Windows. Use the actual paths on your machine; do not assume these examples match your installation.
3. Run a desktop automation script
This complete example starts OperaDriver, tells it which Opera executable to launch, opens a page, prints the title, and cleans up both the browser session and service even if navigation fails.
from selenium import webdriver
from selenium.webdriver.chrome import service
opera_driver_path = "/path/to/operadriver"
opera_binary_path = "/path/to/opera"
webdriver_service = service.Service(executable_path=opera_driver_path)
webdriver_service.start()
options = webdriver.ChromeOptions()
options.binary_location = opera_binary_path
options.add_experimental_option("w3c", True)
driver = None
try:
driver = webdriver.Remote(
command_executor=webdriver_service.service_url,
options=options,
)
driver.get("https://example.com")
print(driver.title)
finally:
if driver is not None:
driver.quit()
webdriver_service.stop()The service and RemoteWebDriver arrangement follows the project’s documented desktop approach. The W3C option appears in that example. Selenium APIs can vary by installed binding version, so if the service constructor or options call differs in your environment, consult the Selenium documentation for that version and adapt the service construction accordingly.
Use a context manager for repeated jobs
For a single short task, the try/finally cleanup above is sufficient. For a test suite, put session creation and teardown in your test framework’s fixture so a failure in one test does not leave Opera processes running. Always call quit() to close the remote session and stop the service that your script started.
4. Choose how Opera is located or connected
The desktop documentation describes three approaches. Start with an explicit binary path when you control the machine and want predictable browser selection.
| Approach | When to use it | What to configure |
|---|---|---|
| Launch an explicit Opera binary | Multiple browsers are installed, or auto-detection selects the wrong one. | Set options.binary_location to the Opera executable path, then connect through the started service. |
| Let the driver detect Opera | Opera is installed in a location the driver can discover and there is no ambiguity. | Use the documented auto-detection approach with empty capabilities/options as appropriate to your binding. If discovery fails, set the binary path explicitly. |
| Attach to an already running Opera instance | You need to connect to a browser you launched separately, for example with a prepared profile or debugging setup. | Launch Opera with --remote-debugging-port=<port>, then configure the matching debugger address in the driver options. Use the same port and keep the browser reachable while the session runs. |
OperaDriver options are similar to ChromeDriver options, and the desktop documentation mentions logPath for browser logs. Use the options supported by your installed driver and Selenium binding; do not assume every ChromeDriver capability is supported identically by every OperaDriver build.
5. Match the OperaDriver release to Opera Stable
Do not select a driver just because its version number resembles Opera’s version. The OperaChromiumDriver releases identify the Opera Stable version they target, and that label is the useful compatibility clue. Compare that target with the version reported by your installed Opera, then use the corresponding driver release.
At the time this research was assembled, the release page listed OperaDriver 152.0.7977.120 for Opera Stable 136, with a September 22, 2026 publication date shown. This is release metadata, not a promise that the same pairing will be current when you read this. Check the official releases page for the current target label.
When a session will not start, capture the exact versions of Selenium, Opera, and OperaDriver before changing settings. A reported 2021 issue described a session-creation error with Opera 81.0.4196.31 and OperaDriver 95.0.4638.54 despite specifying a binary. That individual report illustrates why version and configuration details matter; it does not establish a current general defect.
6. Optional: automate Opera on Android with Appium
The OperaChromiumDriver project also documents an Appium path for Opera on Android. Appium can switch between native UI and web contexts, which may help when a native Opera dialog needs to be dismissed before testing the web page. This is a separate setup from the desktop Selenium example above; follow the project’s Android/Appium documentation for the relevant device and context configuration.
7. Troubleshooting
| Symptom | Likely cause | What to check or change |
|---|---|---|
| Session creation fails | The selected driver release does not target the installed Opera version, or the driver cannot launch the browser. | Compare Opera’s version with the Stable target named on the release entry. Confirm both executable paths and inspect driver logs. Record exact Selenium, Opera, and driver versions. |
| Opera does not launch or the wrong browser opens | The browser path is missing, incorrect, or auto-detection found another installation. | Set options.binary_location to the full Opera executable path and verify the path can be launched by the account running Python. |
| Driver service does not start | The driver path is wrong, its permissions are insufficient, or the downloaded binary is not runnable on the host platform. | Check the file exists, has execute permission where required, and matches the machine’s operating system and architecture. Run the driver directly to inspect startup errors. |
| Connection is refused while attaching to Opera | The browser is not listening on the configured remote debugging port, or the driver is pointed at a different port. | Start Opera with --remote-debugging-port=<port>, keep it running, and make the debugger address use that same port. |
| Constructor or capability errors after upgrading Selenium | The script uses service or capability syntax from a different Selenium binding generation. | Use the Selenium 4 service pattern shown here and consult the docs for the installed binding. The project’s older Selenium 2/3 capabilities example is legacy guidance, not verified syntax for every current binding. |
| Browser opens but navigation or interaction fails | The session may exist while the target page, browser state, or test assumptions differ. | Print the current URL and page title, inspect the browser and driver logs, and verify the page can be reached manually from that host. Add waits for page-specific conditions in the test rather than relying on an arbitrary short delay. |
OperaDriver’s documentation says browser logs can be configured with logPath. Keep logs from the failed run alongside the three version numbers; that makes a compatibility report much more actionable than changing capabilities at random.
8. Performance, reliability, and cost considerations
- Performance: Browser startup and page loading are usually the expensive parts of a browser automation run. Reuse a session for a related sequence of interactions, and avoid repeatedly starting Opera when a test fixture can safely manage one session.
- Reliability: Pin and record the browser, driver, and Selenium versions in reproducible environments. Re-check the release target when upgrading Opera. Use explicit paths in machines with multiple browser installations.
- Parallel runs: If you run multiple browser instances, give each service and any remote-debugging session a distinct available port and isolate browser profiles. Ensure cleanup runs when a test fails.
- Cost: OperaDriver and Selenium are software components; this workflow has no per-screenshot API charge. The machine or CI capacity used to run browser sessions still has an operational cost.
9. Or skip the browser setup
If your task is to capture a page rather than interact with it, ScreenshotNeo offers a one-request screenshot API. For example, this cURL request saves a WebP screenshot of the target page:
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://example.com \
-o shot.webpSee the ScreenshotNeo API documentation for the request options. ScreenshotNeo accepts cookie and consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots.
Learn about ScreenshotNeo, or sign up free for 1,000 screenshots a month, with no card required.
10. Frequently asked questions
Does OperaDriver work with every Opera version?
No universal compatibility guarantee is given. Select the release whose entry names the Opera Stable version you use, and check the release page again when browser versions change.
Can I use the same script with another Selenium language binding?
The project supports Selenium bindings, but the example here is Python. Constructor and option syntax differs between language bindings, so use the corresponding Selenium documentation for your language and version.
Is OperaDriver the right driver for old Presto-based Opera?
No. The OperaChromiumDriver project directs users of Presto-based Opera to OperaPrestoDriver.
When should I use Appium instead of this desktop setup?
Use the documented Appium route when automating Opera on Android, especially if a test needs to move between native UI and web contexts. The desktop Python example is for desktop Opera.
