Selenium Undetected ChromeDriver: How It Works and Where It Hits Its Limits

Undetected ChromeDriver is a patched version of ChromeDriver that removes the most obvious automation signals injected by standard Selenium — but it operates on a desktop Chromium binary whose underlying fingerprint still differs significantly from a real mobile or consumer browser session.

Understanding both what undetected-chromedriver fixes and what it cannot fix helps you choose the right tool for authorized scraping, QA testing, or fingerprinting research.

What Is Undetected ChromeDriver?

Standard Selenium WebDriver sets navigator.webdriver = true in the browser’s JavaScript context. This single boolean is the most straightforward automation signal a detection script can read. The undetected-chromedriver library (often abbreviated uc) addresses this by patching the driver binary and suppressing automation flags at launch time.

What Undetected ChromeDriver Patches

The library also auto-downloads a matching ChromeDriver for your installed Chrome version, reducing version-mismatch signals that some detection systems check.

Where Undetected ChromeDriver Hits Its Limits

Removing navigator.webdriver was sufficient against first-generation bot detectors from the early 2010s. Modern detection services operate across multiple independent layers simultaneously, and undetected-chromedriver does not address most of them.

1. TLS and JA3 Fingerprint

The TLS ClientHello handshake happens at the network layer before any JavaScript runs. Chrome on Linux or Windows produces a different JA3 hash than Chrome on Android or Safari on iOS. Detection proxies operated by Cloudflare, Akamai, and DataDome read this hash and compare it to the declared User-Agent. A “mobile Safari” UA arriving with a desktop Chrome JA3 is an immediate mismatch — no JavaScript patch can fix a signal that never touches JavaScript.

2. Desktop Hardware Signals

Even with a mobile UA string, the browser still reports hardware facts from the underlying desktop:

• WebGL RENDERER — ANGLE (NVIDIA GeForce ...) is a desktop GPU string; Android devices report Adreno, Mali, or Mesa renderers.
• navigator.maxTouchPoints — Returns 0 on a desktop without a touchscreen; real Android devices return 5 or 10.
• Screen dimensions — Match the desktop monitor rather than a mobile viewport.
• Sensor APIs — DeviceMotionEvent and DeviceOrientationEvent return null without physical sensors, which active probes can detect.

3. Canvas and Font Fingerprinting

The <canvas> element renders text and shapes using the OS font renderer and GPU driver. A desktop Linux canvas fingerprint does not match an Android canvas fingerprint regardless of the UA string. Font availability also differs: Windows and Android carry different system font sets, and scripts that probe font presence through canvas width measurements will see the discrepancy.

4. Behavioral and Timing Analysis

Bot-detection vendors analyze mouse movement entropy, scroll velocity, keystroke cadence, and event-timing distributions. Selenium sessions have characteristic timing signatures even when the webdriver flag is removed. Desktop event timing profiles also differ from mobile touch-gesture patterns that real Android users produce.

Summary of Detection Gaps

When Undetected ChromeDriver Is the Right Choice

For many authorized tasks, the remaining detection surface simply does not matter:

• Internal QA testing — Your own staging server is not running a commercial bot detector.
• Lightly protected public data — Sites relying primarily on the navigator.webdriver check are handled by uc alone.
• Desktop-only workflows — If you are automating a desktop web application and mobile fingerprint fidelity is irrelevant to your task.
• Quick prototyping — Undetected-chromedriver requires minimal setup compared to a full containerized Android environment.

If your target performs TLS fingerprint inspection, cross-checks UA against hardware signals, or uses a commercial detection service, you need a solution that addresses the full fingerprint stack.

Damru as an Android-Native Alternative

Damru runs Playwright over CDP inside a Redroid (cloud Android) container. Because the browser is a real Android Chrome build, every fingerprint signal — TLS ClientHello, GPU renderer, touch APIs, sensor feeds, canvas output — originates from the Android OS rather than from JavaScript patches applied to a desktop binary.

This is not a replacement for every use case: undetected-chromedriver is simpler to install and well-suited for desktop workflows. But for mobile fingerprint research or authorized scraping scenarios where desktop-to-mobile consistency is required at every layer, the Android-native stack addresses what JavaScript patches cannot reach.

pip install damru

import asyncio
from damru import AsyncDamru

async def scrape_authorized_endpoint():
    # TLS handshake uses Android's TLS stack — no desktop JA3 leakage
    async with AsyncDamru(device_profile="pixel_8") as browser:
        page = await browser.new_page()
        await page.goto("https://your-authorized-endpoint.com/data")
        # navigator.maxTouchPoints == 10, WebGL reports Adreno renderer
        content = await page.content()
        print(content[:500])

asyncio.run(scrape_authorized_endpoint())

The difference is architectural: undetected-chromedriver patches signals on top of a desktop process; Damru starts from an Android OS where the correct signals are the native defaults. To run many Android workers in parallel and watch any one of them live, use the Damru instance manager.

Choosing the Right Tool

FAQ

What does undetected-chromedriver actually change in the ChromeDriver binary? It patches a specific byte sequence in the driver executable that causes Chrome to omit the navigator.webdriver property and suppresses several automation-mode command-line flags — such as --enable-automation — that standard Selenium injects on launch.

Why can’t a JavaScript patch fix the TLS fingerprint? The TLS ClientHello is sent by the operating system’s network stack before the page loads and before any JavaScript executes. There is no browser JavaScript API that can modify it — addressing the TLS fingerprint requires running on a different OS or TLS stack entirely.

Is undetected-chromedriver maintained for current Chrome versions? The library auto-downloads a matching ChromeDriver version for your installed Chrome, so it generally stays compatible with recent releases. However, significant Chrome architecture changes can temporarily break compatibility until the maintainer updates the patch.

When should I choose Damru over undetected-chromedriver? Choose Damru when you need a genuine Android fingerprint across all layers — real TLS stack, Android GPU renderer, touch APIs, and sensor data. This is necessary for mobile-specific fingerprint research or when a target site cross-validates UA claims against hardware-level signals that JavaScript patches cannot reach.

Related

• See the head-to-head verdict on the undetected-chromedriver alternative page.
• Place both tools in context with Python browser automation and the Python scraping libraries comparison.
• Learn the TLS/JA3 layer that no JavaScript patch can reach.
• Install Damru for an Android-native alternative, or manage and watch a worker pool from the dashboard.