How To Bypass DataDome in 2026

TL;DR — DataDome is one of the strictest anti-bot products on the market because it runs both server-side (TLS/JA3, headers, IP reputation) and client-side (canvas, WebGL, navigator, behaviour) checks and demands you pass both. In 2026 the practical approaches are: archive lookups for stale data, fortified headless browsers + residential proxies for live data, and managed smart-proxy bypasses when you don't want to maintain the bypass yourself.

DataDome is deployed across premium e-commerce, travel, ticketing and classifieds sites where scraper, scalper and fraud activity has a strong financial motive. It's deliberately harder to bypass than CDN-based bot products like Cloudflare — DataDome isn't a CDN, so there's no origin server you can scrape behind it, and its detection runs both before and after the browser receives the page.

With the right tools you can still bypass it reliably. This 2026 guide walks through every working option, in order from easiest to most engineering-intensive:

• Quick reference: DataDome bypass methods
• What is DataDome?
• Option #1: Scrape an Archived Copy
• Option #2: Scrape With Fortified Headless Browsers
• Option #3: TLS Impersonation (curl_cffi)
• Option #4: Anti-Bot Solvers (FlareSolverr)
• Option #5: Smart Proxy With A DataDome Bypass
• Option #6: Reverse Engineer DataDome's Anti-Bot Protection
• Frequently Asked Questions

First, let's get a quick overview of what DataDome is.

Need help scraping the web?

Then check out ScrapeOps, the complete toolkit for web scraping.

Proxy Manager

Scraper Monitoring

Job Scheduling

Quick reference: DataDome bypass methods​

What is DataDome?​

DataDome is an online fraud and bot-management firm that provides a suite of tools to protect web applications from automated abuse — web scraping, scalping, credential stuffing, account takeover, ad fraud, payment fraud and DDoS.

DataDome uses machine-learning models that combine request-level fingerprints (IP reputation, TLS/JA3, HTTP/2 frame settings, header order, browser fingerprint) with behavioural signals (mouse movement, scroll patterns, timing) to produce a per-request risk score, then makes a serve/challenge/block decision in real time.

In contrast to Cloudflare Bot Management, DataDome is not a CDN. There is no origin server you can find and scrape behind it. The only way through DataDome is to make your requests look enough like a real browser-user that the model gives them a low enough risk score to be served the page.

DataDome is commonly deployed on premium e-commerce, classifieds, ticketing and travel sites — anywhere scrapers, scalpers or fraudsters have a strong financial motive to harvest data or hold inventory.

Option #1: Scrape an Archived Copy​

If the data you need doesn't have to be fresh, the simplest possible bypass is to skip DataDome entirely and read an already-archived copy of the page. Several public archives crawl the web from datacenter ranges that DataDome doesn't apply its full protection to:

The most reliable way to fetch the latest Wayback snapshot for a URL is to hit the year-prefixed redirect URL — https://web.archive.org/web/<YEAR>/<URL> — and let archive.org redirect you to the closest snapshot. This is more robust than the Wayback Availability API, which we've found can return empty responses or 503s under load:

import requests

target = "https://www.example.com/product/12345"

# Year-prefixed redirect — Wayback resolves this to the closest snapshot.
# `allow_redirects=True` follows through to the final web.archive.org/web/<timestamp>/... URL.
r = requests.get(f"https://web.archive.org/web/2026/{target}", timeout=30, allow_redirects=True)
if r.status_code == 200:
    snapshot_url = r.url  # final URL after redirect, e.g. https://web.archive.org/web/20260512143012/...
    html = r.text
    # ... parse data from html

# If you also need snapshot metadata (timestamp etc.), the Availability API gives JSON:
api = "https://archive.org/wayback/available"
r = requests.get(api, params={"url": target}, timeout=30)
if r.ok:
    snap = r.json().get("archived_snapshots", {}).get("closest")
    if snap and snap.get("available"):
        print(snap["timestamp"], snap["url"])

Option #2: Scrape With Fortified Headless Browsers​

If you need fresh data, the next-simplest approach is to do the scraping with a headless browser that has been fortified to look like a real user's browser. Vanilla Chrome/Firefox driven by automation tools leaks its identity in dozens of JavaScript fingerprints — navigator.webdriver, window.chrome, the absence of plugins, headless-specific user-agent strings, deterministic timing — and DataDome's client-side script reads all of them.

There is now a mature ecosystem of fortified browsers and patches that close most of these leaks. The four most widely used in 2026:

• undetected-chromedriver — the original Selenium-based fortified Chromedriver. Still the most widely-deployed option.
• nodriver — successor to undetected-chromedriver from the same author; uses the Chrome DevTools Protocol directly (no Selenium), which makes it faster and harder to fingerprint.
• puppeteer-extra + puppeteer-extra-plugin-stealth — the Puppeteer-flavour stealth plugin.
• playwright-extra and rebrowser-patches — the Playwright equivalents, used together for the strongest leak coverage.
• camoufox — a Firefox-based stealth browser with leak-fixing patches built into the browser itself rather than injected from JavaScript.

Each closes a different subset of the ~200 known headless-browser leaks. A common starting leak is the value of navigator.webdriver — in normal browsers it's false, in unfortified headless browsers it's true:

Stealth plugins patch most of the headless-browser leaks at the JavaScript level. They can bypass a large fraction of anti-bot services — including DataDome, Imperva and Cloudflare — at lower security levels. At DataDome's strictest configurations, even fortified browsers occasionally need supplementary patches.

DataDome scores IP reputation aggressively — much more so than most other anti-bot solutions. In practice this means you will almost always need to pair the fortified browser with residential or mobile proxies to actually pass. Even a perfectly fortified browser will be blocked from a flagged datacenter IP range.

Residential and mobile proxies are charged per GB of bandwidth used, and a page rendered with a headless browser consumes around 2 MB on average (vs ~250 KB without one) — costs can rack up fast at scale:

The following is an example of using residential proxies from BrightData with a headless browser assuming 2MB per page.

Example: Selenium Undetected ChromeDriver​

Here's how you'd use undetected-chromedriver to scrape a DataDome-protected site.

First, install the package:

pip install undetected-chromedriver

Then drive it just like a normal Selenium WebDriver:

import undetected_chromedriver as uc

driver = uc.Chrome()
driver.get('https://datadome.co/')

For an authenticated residential proxy (almost always required against DataDome), the recommended 2026 approach is to load a small in-memory Chrome extension that handles the proxy auth dialog — see the full code in our Selenium proxy guide. selenium-wire's undetected_chromedriver integration used to be the shortcut here, but selenium-wire is no longer actively maintained and is best avoided for new projects.

The standard Selenium ChromeDriver leaks a lot of information that anti-bot systems use to spot automation. undetected-chromedriver patches the vast majority of those leaks — making it much harder for DataDome, Imperva, PerimeterX/HUMAN and Cloudflare to detect a Selenium client.

For deeper coverage of undetected-chromedriver, see our full guide here.

Option #3: TLS Impersonation (curl_cffi)​

If the DataDome configuration you're hitting only fires server-side checks (TLS, HTTP/2, headers, IP) — no client-side script challenge — you can skip the browser entirely and use TLS impersonation from a regular HTTP client. This is dramatically lighter than running a headless browser and gives you much higher throughput.

In Python, curl_cffi is the standard tool: it's a requests-compatible client backed by libcurl-impersonate that produces the exact JA3/JA4 TLS fingerprint and HTTP/2 settings frame of a real Chrome (or Firefox, Edge, Safari) install:

# pip install curl_cffi
from curl_cffi import requests

# `impersonate="chrome124"` makes the TLS handshake, HTTP/2 settings frame
# and default header order all match real Chrome 124.
PROXY = "http://user:pass@residential.proxy.example.com:8000"

r = requests.get(
    "https://www.example-datadome-site.com/",
    impersonate="chrome124",
    proxies={"http": PROXY, "https": PROXY},
    timeout=30,
)
print(r.status_code, len(r.text))

A few notes on TLS impersonation against DataDome specifically:

• It only solves the server-side half of the detection. If the response includes a DataDome challenge script (look for dd-captcha, datadome cookies, or a /captcha/?initialCid=... redirect), you'll need a real browser (Option #2) on top.
• It is highly sensitive to the proxy IP. DataDome's IP-reputation model is one of the strictest in the industry — without residential or mobile proxies, even a perfect TLS fingerprint will get blocked.
• The same approach is available inside Scrapy via scrapy-impersonate. See our Scrapy 403 guide for the integration details.

You can check the TLS fingerprint your client and proxy combination is presenting at tls.peet.ws — useful debugging when DataDome blocks you and you need to find out which layer is leaking.

Option #4: Anti-Bot Solvers (FlareSolverr)​

Another way to bypass DataDome is to use general-purpose anti-bot solvers — the most popular being FlareSolverr, which was originally built for Cloudflare.

There is no open-source solver specifically designed for DataDome (that we know of), but solvers built around fortified browsers can incidentally work against DataDome in some configurations.

FlareSolverr is a Docker-distributed HTTP proxy server that drives Chromium via undetected-chromedriver. It opens the target URL in the headless browser, waits for the challenge to clear, and returns the resulting HTML plus cookies. Because the underlying fortified-browser tech is the same kind that bypasses DataDome at lower security levels, FlareSolverr can clear some DataDome configurations — but its detection logic was built for Cloudflare, so it doesn't report DataDome-specific failure states cleanly. Treat FlareSolverr as a cheap experiment for DataDome rather than a production-grade solution.

For full coverage of FlareSolverr, see our FlareSolverr guide.

To run it, pull and start the Docker image:

docker run -d \
  --name=flaresolverr \
  -p 8191:8191 \
  -e LOG_LEVEL=info \
  --restart unless-stopped \
  ghcr.io/flaresolverr/flaresolverr:latest

Then point your scraper at the FlareSolverr server:

import requests

post_body = {
  "cmd": "request.get",
  "url": "https://www.example-datadome-site.com/",
  "maxTimeout": 60000,
}

response = requests.post(
    "http://localhost:8191/v1",
    headers={"Content-Type": "application/json"},
    json=post_body,
)
print(response.json())

A successful response includes the resulting cookies (including the datadome cookie) and the HTML body. Because FlareSolverr was built for Cloudflare, it does not detect DataDome challenges or bans natively — you need to validate the response yourself (check for a DataDome captcha page in the HTML, the datadome cookie's value, or whether the response actually contains the data you expect).

Option #5: Smart Proxy With A DataDome Bypass​

The downside of open-source bypasses — Options #2, #3 and #4 — is that DataDome can see how they work and ship patches. Open-source bypasses against the strictest configurations typically have a short shelf life before they need updating.

The alternative to using open source DataDome bypasses, is to use smart proxies that develop and maintain their own private DataDome bypass.

These are typically more reliable as it is harder for DataDome to develop patches for them, and they are developed by proxy companies who are financially motivated to stay 1 step ahead of DataDome and fix their bypasses the very minute they stop working.

One of the best options is to use the ScrapeOps Proxy Aggregator as it integrates over 20 proxy providers into the same proxy API, and finds the best/cheapest proxy provider for your target domains.

You can activate ScrapeOps' DataDome Bypass by simply adding bypass=datadome to your API request, and the ScrapeOps proxy will use the best & cheapest DataDome bypass available for your target domain.

import requests

response = requests.get(
  url='https://proxy.scrapeops.io/v1/',
  params={
      'api_key': 'YOUR_API_KEY',
      'url': 'https://datadome.co/', ## DataDome protected website 
      'bypass': 'datadome',
  },
)

print('Body: ', response.content)

You can get a ScrapeOps API key with 1,000 free API credits by signing up here.

The advantage of taking this approach is that you can use your normal HTTP client and don't have to worry about:

• Fortifying headless browsers
• Managing numerous headless browser instances & dealing with memory issues
• Reverse engineering the DataDome's anti-bot protection

As this is all managed within the ScrapeOps Proxy Aggregator.

Option #6: Reverse Engineer DataDome's Anti-Bot Protection​

The most engineering-intensive way to bypass DataDome is to reverse-engineer its detection system and build a custom bypass that passes every check without needing a full headless browser.

Technically this is possible, but unlike reverse-engineering other anti-bot systems like Cloudflare and PerimeterX, reverse-engineering DataDome is dramatically harder — DataDome's client-side script is heavily obfuscated, frequently updated, and combines fingerprint checks with behavioural signals that are hard to reproduce without an actual browser.

DataDome's bot detection system can be split into two categories:

• Backend Detection Techniques: These are bot fingerprinting techniques that are performed on the backend server.
• Client-Side Detection Techniques: These are bot fingerprinting techniques that are performed in the users browser (client-side).

To bypass DataDome you must pass both sets of verficiation tests:

Passing DataDome's Backend Detection Techniques​

The following are the known backend bot fingerprinting techniques DataDome performs on the server side prior to returning a HTML response and how to pass them:

#1: IP Quality​

One of the most fundamental tests DataDome conducts is computing a IP address reputation score for the IP addresses you use to send requests. Taking into account factors like is it known to be part of any known bot networks, its location, ISP, reputation history.

To obtain the highest IP address reputation scores you should use residential/mobile proxies over datacenter proxies or any proxies associated with VPNs. However, datacenter proxies can still work if they are high quality.

#2: HTTP Browser Headers​

DataDome analyses the HTTP headers you send with your requests and compares them to a database of known browser headers patterns.

Most HTTP clients send user-agents and other headers that clearly identify them by default, so you need to override these headers and use a complete set of browser headers that match the type of browser you want to appear as. In this header optimization guide, we go into detail on how to do this and you can use our free Fake Browser Headers API to generate a list of fake browser headers.

#3: TLS & HTTP/2 Fingerprints​

DataDome also uses is TLS & HTTP/2 fingerprinting which is a much more complex anti-bot detection method. Every HTTP request client generates a static TLS and HTTP/2 fingerprint that DataDome can use to determine if the request is coming from a real user or bot.

Different versions of browsers and HTTP clients tend to posess different TLS and HTTP/2 fingerprints which DataDome can then compare to the browser headers you send to match sure that you really are who claim to be in the browser headers you set.

The problem is that faking TLS and HTTP/2 fingerprints is much harder than simply adding fake browser headers to your request. You first need to capture and analyze the packets from the browsers you want to impersonate, then alter the TLS and HTTP/2 fingerprints used to make the request.

However, many HTTP clients like Python Requests don't give you the ability to alter these TLS and HTTP/2 fingerprints. You will need to use programming languages and HTTP client like Golang HTTP or Got which gives you enough low-level control of the request that you can fake the TLS and HTTP/2 fingerprints.

Libraries like CycleTLS, Got Scraping. utls help you spoof TLS/JA3 fingerprints in GO and Javascript.

This is a complicated topic, so I would suggest you dive into how TLS & HTTP/2 fingerprinting works. Here are some resources to help you:

• Passive Fingerprinting of HTTP/2 Clients (Akami White Paper, 2017)
• What happens in a TLS handshake?
• TLS Fingerprinting with JA3 and JA3S

DataDome's server-side detection techniques is its first line of defence. If you fail any of these tests your request will be challenged with a DataDome CAPTCHA page or blocked completely by DataDome.

The server-side detection techniques assign your request a risk score which DataDome then uses to determine if client side.

Each individual website can set their own anti-bot protection risk thresholds, to determine who should be challenged and with what challenges (background client-side challenges or CAPTCHAs). So your goal is to obtain the lowest risk score possible. Especially for the most protected websites.

Passing DataDome's Client-Side Detection​

Okay, assuming you've been able to build a system to pass all DataDome's server-side anti-bot checks, now you need to deal with its client-side verfication tests.

The following are the main client-side bot fingerprinting techniques DataDome performs in the users browser which you will need to pass:

#1: Browser Web APIs​

Modern browsers have hundreds of APIs that allow us as developers to design apps that interact with the users browser. Unfortuntately, when DataDome loads in the users browser it gets access to all these APIs too.

Allowing it to access huge amounts of information about the browser environment, that it can then use to detect scrapers lying about their true identies. For example DataDome can query:

1. Browser-Specific APIs: Some web APIs like window.chrome only exists on a Chrome browser. So if your browser headers, TLS and HTTP/2 fingerprints all say that you are making a request with a Chrome browser, but the window.chrome API doesn't exist when DataDome checks the browser then it is a clear sign that you are faking your fingerprints.
2. Automated Browser APIs: Automated browsers like Selenium have APIs like window.document.__selenium_unwrapped. If DataDome sees that these APIs exist then it knows you aren't a real user.
3. Sandbox Browser Emulatator APIs: Sandboxed browser browser emulators like JSDOM, which runs in NodeJs, has the process object which only exists in NodeJs.
4. Environment APIs: If your user-agent is saying you are using a MacOs or Windows machine but the navigator.platform value is set to Linux x86_64, then that makes your request look suspicious.

If you are using a fortified browser it will have fixed a lot of these leaks, however, you will likely have to fix more and make sure that your browser headers and TLS & HTTP/2 fingerprints match the values returned from the browser web APIs.

#2: Canvas Fingerprinting​

DataDome uses canvas fingerprinting libraries like WebGL to render an image and create a canvas fingerprint.

Canvas fingerprinting is a technique that allows DataDome to classify the type of device being used (combination of browser, operating system, and graphics hardware of the system).

Canvas fingerprinting is one of the most common browser fingerprinting techniques that uses the HTML5 API to draw graphics and animations of a page with Javascript, which can then be used to product a fingerprint of the device.

DataDome maintains a large dataset of legitimate canvas fingerprints and user-agent pairs. So when a request is coming from a user who is claiming to be a Firefox browser running on a Windows machine in their headers, but their canvas fingerprint is saying they are actually a Chrome browser running on a Linux machine then is a sign for DataDome to challenge or block the request.

#3: Event Tracking​

If you need to mavigate around or interact with a web page to get the data you need, then you will have to contend with DataDome's event tracking.

DataDome adds event listeners to webpages so that it can monitor user actions like mouse movements, clicks, and key presses. If you have a scraper that need to interacts with a page, but the mouse never moves then it is a clear sign to DataDome that the request is coming from an automated browser and not a real user.

Frequently Asked Questions​

More Web Scraping Guides​

When it comes to bypassing DataDome you have multiple options — some quick and easy, some much more complex. Each has its own tradeoffs.

If you'd like to learn how to scrape some popular websites then check out our other How To Scrape Guides:

• How To Scrape Amazon.com
• How To Scrape Walmart.com
• How To Scrape Indeed.com

Or if you'd like to learn more about web scraping in general, then be sure to check out The Web Scraping Playbook, or one of our deeper guides:

• How To Bypass Cloudflare — the companion guide for the other major anti-bot product.
• How To Solve 403 Forbidden Errors When Web Scraping — covers the TLS-fingerprinting layer DataDome relies on.
• How to Scrape The Web Without Getting Blocked Guide
• The Ethics of Web Scraping