Selenium Antidetect — Python Automation Tutorial (Step-by-Step)

Combining Selenium with an antidetect browser gives you scriptable automation with fingerprint isolation per profile. This guide shows how to connect, how to avoid webdriver detection, and what the working code looks like end-to-end.

Why automation needs antidetect more than manual browsing

Plain Selenium driving a vanilla Chrome leaks one big signal that real users never have: an automation flag visible to web pages. Sites check this signal and immediately know you're an automation script. Plus the regular Chrome you're driving has your default fingerprint, so even if you hide the automation flag, you still look like one specific user across every script run.

A good antidetect browser handles both — each profile shows a different fingerprint to web pages, and automation signals are suppressed in a way that's robust against common detection scripts. Persistent cookies per profile mean sessions survive between runs.

If you've ever wondered why your Selenium scripts get caught faster than your manual browsing, this is why.

Two common ways to connect Selenium

Most antidetect browsers expose two integration patterns. Specific endpoints and APIs vary by product — check your provider's documentation for the exact commands.

Pattern A — Attach to a running profile

The antidetect browser launches a Chromium window with a debug port. Your script connects to that port using the standard Chrome DevTools Protocol. This is the same model as headless automation in production CI.

Pattern B — Launch a profile from your script

You call the antidetect product's local API to start a profile, get back the debug port, then connect Selenium. Useful when you need to pick which profile to run dynamically.

Pattern B is more flexible and what most production setups use.

Prerequisites

• Antidetect browser installed and activated
• At least one profile created (some products also offer ephemeral one-shot mode)
• Python 3.10+ with selenium installed: pip install selenium requests
• An API key or token from your antidetect browser's account page (needed for Pattern B)

Pattern A — Attach to a launched profile

Launch the profile manually in the UI. Most antidetect browsers print or expose the debug port. Then:

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

# replace with port shown by your antidetect browser
DEBUG_PORT = 9222

opts = Options()
opts.add_experimental_option("debuggerAddress", f"127.0.0.1:{DEBUG_PORT}")
driver = webdriver.Chrome(options=opts)

driver.get("https://pixelscan.net")
print(driver.title)
driver.quit()

That's it. Selenium now drives the antidetect Chrome window. Fingerprint values stay as the profile defines them.

Pattern B — Launch via API + attach

This is the production pattern. The exact API calls depend on your antidetect product — check your provider's documentation for the specific endpoints and authentication style. The flow is the same across products:

1. List profiles your account has access to

2. Pick a profile by name, tag, or any criteria

3. Ask the antidetect app to launch it — the response tells you which debug port to attach to

4. Attach Selenium to that port using the standard debuggerAddress option

5. When done, tell the antidetect app to stop the session

Pseudocode:

# Step 1-2: pick a profile from the list
profiles = antidetect_client.list_profiles()
target = next(p for p in profiles if p["name"] == "shop-1")

# Step 3: launch and get the debug address
launch_info = antidetect_client.launch(target["id"])
debug_address = launch_info["debug_address"]

# Step 4: attach Selenium (this part is identical across products)
opts = webdriver.ChromeOptions()
opts.add_experimental_option("debuggerAddress", debug_address)
driver = webdriver.Chrome(options=opts)

try:
    driver.get("https://pixelscan.net")
    # ... your work ...
finally:
    driver.quit()
    # Step 5: clean up the session
    antidetect_client.stop(launch_info["session_id"])

The flow is straightforward: pick a profile, ask for a debug address, attach Selenium, work, clean up.

Things that go wrong (common bugs)

session not created: Chrome version must be between X and Y

selenium installs a chromedriver matched to standard Chrome. Antidetect browsers use a custom browser build that may report a different version. Solution: pin chromedriver explicitly or use Selenium 4.6+ which auto-resolves via Selenium Manager.

Connection refused

The debug port from the API isn't ready by the time you call webdriver.Chrome. Sleep 1 second between API response and Selenium attach, or retry-with-backoff.

Profile data corrupted

You crashed Selenium without calling /browser/stop. The antidetect browser thinks the profile is still in use. Restart the antidetect manager from its tray icon.

Fingerprint changes across runs of the same profile

The profile should give you the same fingerprint every time. If it varies, the antidetect browser is regenerating per-run (some products do this by default). Check profile settings — there should be a "stable fingerprint" or "deterministic seed" option.

Site still detects you as bot

The automation flag is one signal but not the only one. Sites also check:

• Automation-specific Chrome flags (--enable-automation, --remote-debugging-port)
• CDP-specific properties leaked to page
• Behavioral signals (no mouse movement, perfectly-timed clicks, no typing delays)

A real antidetect browser handles the first two at the C++ patch level. For behavioral, you write your script with realistic delays (time.sleep(random.uniform(0.5, 1.5)) between actions, simulated mouse paths if possible).

Playwright instead of Selenium

Selenium is the most common, but Playwright works the same way:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(f"http://{debug_address}")
    context = browser.contexts[0]
    page = context.new_page()
    page.goto("https://pixelscan.net")
    print(page.title())
    browser.close()

Playwright's CDP attach is similar. Use whichever your team prefers.

Production patterns

• Pool of profiles — launch N profiles concurrently, each in its own thread, distribute work
• Health check — before assigning work to a profile, verify the antidetect app is alive (most products have a status endpoint)
• Retry with new profile on failure — if a profile gets soft-banned, fall back to another rather than retry-loop
• Ephemeral profiles for one-shot tasks — some products offer a mode where each call gets a fresh fingerprint without saving cookies. Useful when you don't need session persistence

The ephemeral pattern is especially useful for tasks like ad verification or competitor price scraping where each request should look like a different user.

FAQ