Skip to main content
Selenium WebDriver support is deprecated and not recommended for new installations. Use Playwright instead for better performance, full-page screenshots, HTTP status code reporting, and Browser Steps support.

What Selenium WebDriver Provides

Selenium WebDriver offers basic browser automation through the legacy WebDriver protocol:
  • JavaScript Rendering - Execute JavaScript and wait for content to load
  • Basic Screenshots - Viewport-only PNG screenshots (no full-page capture)
  • Chrome Browser - Uses Selenium Standalone Chrome container
  • XPath Element Data - Extract structured data from page elements
  • Proxy Support - Basic proxy configuration via Chrome options

Limitations

Important limitations compared to Playwright:
  • No Browser Steps Support - Cannot automate interactions like clicking or form filling
  • No Full-Page Screenshots - Only captures visible viewport, not entire scrollable page
  • No Status Code Reporting - Always reports 200 OK, regardless of actual HTTP response
  • No Visual Selector - Point-and-click element selection not available
  • Limited Error Handling - Cannot detect actual page load errors
  • Single-Process Limitation - Selenium hub allows only one concurrent browser by default
  • Legacy Technology - Based on older WebDriver protocol

Docker Configuration

To use Selenium WebDriver, run a Selenium Standalone Chrome service alongside changedetection.io.

Using docker-compose.yml

Uncomment the Selenium service in your docker-compose.yml:

Docker Standalone

If running without docker-compose:

Environment Variables

Required Configuration

WEBDRIVER_URL - HTTP URL to the Selenium hub

Optional Configuration

WEBDRIVER_DELAY_BEFORE_CONTENT_READY - Seconds to wait after page load (default: 5)
WEBDRIVER_PAGELOAD_TIMEOUT - Seconds to wait for page load (default: 45)
CHROME_OPTIONS - Chrome command-line arguments (multiline)
SCREENSHOT_QUALITY - JPEG quality for converted screenshots (default: 72)

Proxy Configuration

WebDriver uses Chrome proxy options with the webdriver_ prefix:

When to Use Selenium WebDriver

In almost all cases, you should use Playwright instead.
Consider Selenium only if:
  • You already have Selenium infrastructure deployed
  • You need compatibility with existing Selenium-based workflows
  • You’re migrating from an older changedetection.io version that used Selenium
For new installations, use Playwright for:
  • Full-page screenshots
  • HTTP status code detection
  • Browser Steps automation
  • Better performance
  • Active development and support

JavaScript Rendering

Selenium executes JavaScript on the page with basic waiting:

Custom JavaScript Execution

Set in watch configuration under “Execute JavaScript before page extraction”.

Render Delays

Selenium waits using implicitly_wait():
  1. Navigate to page
  2. Wait for initial DOM load
  3. Wait WEBDRIVER_DELAY_BEFORE_CONTENT_READY seconds
  4. Execute custom JavaScript (if configured)
  5. Wait another WEBDRIVER_DELAY_BEFORE_CONTENT_READY seconds
  6. Capture content
Selenium’s waiting is less sophisticated than Playwright’s network idle detection.

Screenshots

Screenshot Limitations

Selenium screenshots have significant limitations:
  • Viewport Only - Only captures what’s visible in browser window
  • No Scrolling - Cannot capture content below the fold
  • Fixed Size - Screenshot size matches window size (1280x1024 default)
  • PNG Only - Captures as PNG, then converts to JPEG if requested
  • No Stitching - No automatic full-page capture

Screenshot Formats

PNG (native format)
  • Lossless quality
  • Larger file size
  • No conversion overhead
JPEG (converted from PNG)
  • Smaller file size
  • Quality loss from conversion
  • Uses SCREENSHOT_QUALITY setting
  • RGB conversion handles transparency

Window Sizing

Control screenshot size via CHROME_OPTIONS:
Or set at runtime (default if not specified):
Since Selenium only captures the viewport, tall pages will be cropped. Use Playwright for full-page screenshots.

Performance Considerations

Resource Usage

Memory
  • Selenium hub: ~500MB base
  • Chrome browser: ~200-400MB per instance
  • Screenshots: ~2-10MB (viewport only)
CPU
  • Page rendering
  • JavaScript execution
  • Screenshot PNG encoding
  • JPEG conversion (if using JPEG format)
Limitations
  • Default Selenium standalone allows only 1 concurrent session
  • Need Selenium Grid for multiple concurrent browsers
  • Slower startup than Playwright

Speed Comparison

Troubleshooting

Connection Issues

Browser Crashes

If Chrome crashes inside the container:
Or add Chrome options:

Memory Issues

Timeout Errors

”Session already exists” Error

Selenium standalone only allows one session at a time:

Migrating to Playwright

If you’re currently using Selenium, migrating to Playwright is straightforward:

Step 1: Update docker-compose.yml

Step 2: Update Environment Variables

Step 3: Restart Services

What You Gain

  • Full-page screenshots instead of viewport-only
  • Actual HTTP status codes (200, 404, 403, etc.)
  • Browser Steps automation support
  • Visual Selector tool
  • Better performance and reliability
  • Multiple concurrent browsers
  • Active development and updates

What Stays the Same

  • Custom JavaScript execution
  • XPath and CSS selectors
  • Proxy configuration (just change prefix)
  • Screenshot capture
  • Watch configuration

Comparison with Playwright

Advanced Configuration

Custom Chrome Options

Full list of supported Chrome arguments:

Selenium Grid (Multi-Session)

For concurrent browsers, use Selenium Grid instead of standalone:
Then connect:

Remote Selenium Hub

Connect to external Selenium services:

Why Selenium is Deprecated

The Selenium WebDriver integration has several architectural limitations:
  1. No Status Reporting - WebDriver protocol doesn’t expose HTTP response codes
  2. Screenshot Limitations - WebDriver API only supports viewport capture
  3. Single Process - Selenium standalone design limits concurrency
  4. No Automation - WebDriver protocol doesn’t support Browser Steps workflow
  5. Slower Performance - Extra HTTP overhead compared to CDP-based protocols
  6. Maintenance Burden - Requires separate Selenium hub infrastructure
Playwright uses the Chrome DevTools Protocol (CDP) directly, which provides:
  • Direct access to HTTP responses
  • Native full-page screenshot support
  • WebSocket connection (lower latency)
  • Network event monitoring
  • Better automation APIs