Here is everything I know about scraping

They built walls.
I spent 7 years finding doors.

I started scraping in 2018. Since then I have worked across five companies, built hundreds of production spiders, and fought every major anti-bot system that exists. This guide is everything that actually worked.

JA4+ TLS Fingerprinting Scrapy Playwright Akamai Cloudflare DataDome Kasada F5 Shape AI Scraping MCP Tools curl_cffi Camoufox Scrapling
6
Anti-bots
60+
Libraries
4
Detection layers
6
Decision steps

Paste into Claude, ChatGPT, or Cursor — full guide as LLM context

Scroll
About the author
7 years of production scraping
Asad Ikram
Data Engineer & Scraping specialist

I started scraping the web in 2018. Since then I have worked at five companies including Fix.com, Dubizzle Labsand M+C Saatchi Fluencybuilding production scrapers at scale across MENA and Europe.

Currently Data Engineer at M+C Saatchi Fluency and co-founder of ArtemisAI Ltd. Chevening Scholar 2024/25, MSc Data Analytics with Distinction.

I built this guide to share everything I know about scraping properly, the bypasses, the failures, the patterns that hold up in production. No guesswork, no generic tutorials.

Portfolio LinkedIn
🕷️
500+
Production spiders built
📊
50M+
Data points extracted
🏢
5+
Companies with production scrapers
🎓
2024
Chevening Scholar, UK Govt
01 Attack strategy

The scraping
decision flow

Walk steps in order. Stop at the first win. Complexity and cost increase right. Most production scraping is solved at steps 1–3.

Recon first (Step 0): Before picking a step from the flow, capture a real session through Burp Suite and run PortSwigger's MCP server with Claude Code. One prompt traces the entire cookie lifecycle (_abck, cf_clearance, datadome, reese84), identifies sensor payload endpoints, and tells you which step from the flow below will actually work for this target. What used to be a 4-hour manual walk through HTTP history is now a 2-minute prompt.
Asad's Priority Order, start left, move right only when needed
Step 1
📱
Mobile API
HTTPToolkit
Frida · mitmproxy
Step 2
🔍
XHR Endpoint
Chrome DevTools
Burp + MCP · webclaw
Step 3
🗃️
JSON in HTML
__NEXT_DATA__
chompjs · Parsel
Step 4
HTTP Scraping
curl_cffi
Scrapy · Scrapling
Step 5
🌐
C++ Browser
Camoufox
CloakBrowser
Step 6
☁️
Managed API
Bright Data
Zyte · Firecrawl
Rule #1, Asad's priority: Never start at Step 5. The mobile app often hits the same backend with zero anti-bot. Confirmed on a major retailer, a direct GraphQL endpoint bypassed all HTML anti-bot protection entirely. Find the API first, always.
Before we go deeper: The flow above tells you what order to try things. But to understand why those steps exist in that order, and what happens when you skip one, you need to understand how detection actually works. The next section breaks down every signal anti-bots collect, starting at the TCP handshake.

The six steps above tell you what order to try. But to know which step to stop at, and why skipping ahead costs you days, you first need to understand how the detection actually works. Let's go deeper.

02 The anatomy of detection

Before you send a single byte,
you've already been judged.

The moment your scraper opens a TCP connection to a CDN, a fingerprinting pipeline triggers. By the time your HTTP request body arrives, four independent scoring systems have already assigned you a trust score. Here's exactly what each one measures, and why defeating just one is never enough.

The fundamental insight: Anti-bots don't make binary decisions. They assign a continuous trust score across all four layers simultaneously. A perfect TLS fingerprint with a datacenter IP and machine-like mouse movement still fails, just at a different layer. The only winning strategy is addressing all four at once.

Layer 1, TLS Fingerprinting: The Handshake That Betrays You

This fires before a single HTTP byte is exchanged. Understanding it is non-negotiable.

Origin 2017 · Salesforce Research
JA3, The First Fingerprint
When any HTTPS client connects, it sends a TLS ClientHello message. JA3 extracts five fields from it and MD5-hashes the combination:

TLS Version + Cipher Suites + Extensions + Elliptic Curves + Curve Formats

This produced a stable 32-char hex hash. Python's requests library has always had the same JA3 hash. Every major anti-bot catalogued it. By 2021, your Python scraper was identifiable before the first HTTP header.

JA3's weakness: Chrome started randomising TLS extension order in 2022. Same browser, different JA3 every session. The fingerprint became unstable and unreliable.
2023 · FoxIO · Replaces JA3
JA4+, The Unbreakable Standard
JA4 was engineered specifically to survive Chrome's randomisation. Instead of hashing raw extension order, it sorts extensions alphabetically and removes GREASE values before hashing. The result is stable regardless of Chrome's ordering.

JA4 format: t13d1516h2_8daaf6152771_b0da82dd1658
, t13 = TLS 1.3, d = DTLS, 1516 = cipher count+length hash, h2 = ALPN (HTTP/2), remainder = extension hash

JA4+ extends this with: JA4H (HTTP header fingerprint), JA4X (X.509 certificate), JA4SSH (SSH handshake), JA4T (TCP window + options). Cloudflare deployed it in a Rust crate at CDN edge. Akamai in an EdgeWorker. Both fire before your request reaches origin.
HTTP/2 · Wireshark Observable
HTTP/2 Frame Fingerprinting
Even with a perfect JA4 hash, HTTP/2 itself leaks your client identity. The SETTINGS frame that every HTTP/2 client sends at connection start has parameters that vary by implementation:

HEADER_TABLE_SIZE, MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE, MAX_FRAME_SIZE, MAX_HEADER_LIST_SIZE

Chrome's exact values are documented. Python's httpx sends different values. curl sends different values. The ordering of these settings, the window update frame sizes, and the HPACK compression decisions all create a secondary fingerprint that cannot be spoofed without rewriting the HTTP/2 clientwhich is exactly what curl_cffi does.
2024+ · Emerging Standard
QUIC / HTTP/3 Fingerprinting
As HTTP/3 adoption grows, JA4Q and QUIC Initial packet fingerprinting are being deployed. QUIC's handshake carries its own fingerprint surface: connection ID length, transport parameters, initial packet number, token presence.

Chrome's QUIC stack differs from libcurl's QUIC implementation differs from Python's aioquic. Each leaves a unique signature in the Initial packets.

Current status: JA4+ covers QUIC. Cloudflare has begun collecting QUIC fingerprints. Not yet widely enforced for blocking, but the infrastructure is live. Tools like curl_cffi are actively implementing QUIC parity.
python
# Test your actual JA4 fingerprint against tls.browserleaks.com
import requests
from curl_cffi import requests as cffi

# ❌ requests, exposes Python/urllib3 JA4, blocked immediately
r1 = requests.get("https://tls.browserleaks.com/json")
print(r1.json()["ja4"])
# → t13d1516h2_8daaf6152771_b0da82dd1658  (Python fingerprint, catalogued, blocked)

# ✓ curl_cffi, emits Chrome 124's exact JA4 hash, HTTP/2 frames, cipher order
r2 = cffi.get(
    "https://tls.browserleaks.com/json"
    impersonate="chrome124"  # also: chrome110, chrome107, safari17
)
print(r2.json()["ja4"])
# → t13d1517h2_c4b4b4b4b4b4_aaaaaaaaaa   (Chrome 124 fingerprint, passes)

# Also check HTTP/2 fingerprint
print(r2.json()["http2"])  # Chrome's exact SETTINGS frame values
Practical · How to actually spoof TLS in 2026
From theory to working code

All the JA4+ research is academic until you ship it. Three tiers of solution, in order of how often you should reach for each:

Tier 1 · 80% of cases
Use a TLS-impersonating HTTP client
curl_cffi (Python), tls-client (Go), noble-tls, hrequests. One line of code, exact Chrome/Firefox JA4. Drop-in replacement for requests.

curl_cffi.requests.get(url, impersonate="chrome131")
Tier 2 · Scrapy projects
Plug a stealth middleware in
scrapy-stealth adds TLS + HTTP/2 fingerprinting + proxy rotation + fingerprint cycling to existing Scrapy spiders via DOWNLOADER_MIDDLEWARE. Per-request engine switching keeps simple URLs fast.

meta={"stealth": {"profile": "chrome_147"}}
Tier 3 · Hardest targets
Browser with C++ patches
When TLS spoofing alone fails (Akamai extension probes, Kasada toString checks, behavioural ML), reach for Camoufox, rayobrowse, or CloakBrowser. C++ binary patches ship a real-browser TLS stack along with everything else.

Cost: 200MB+ memory per browser instance
⚠ Common mistakes
1. Spoofing User-Agent without TLS. If your UA says Chrome but JA4 says Python urllib3, you flag faster than no spoofing at all, the mismatch is the signal.
2. Forgetting HTTP/2 SETTINGS frames. Even perfect JA4 fails if your HTTP/2 SETTINGS (header table size, max concurrent streams, initial window size) do not match the browser you claim to be. curl_cffi and tls-client handle this; rolling your own usually does not.
3. Using stale impersonation profiles. Chrome 120 fingerprints in 2026 are themselves suspicious, real users rolled forward. Keep impersonate="chrome131" or newer.

Layer 2, JavaScript Fingerprinting: The Page That Interrogates You

2026 update: Microsoft Edge now silently returns navigator.webdriver = false for AI-agent-driven Playwright sessions, and Google patched out the most common CDP-detection technique in V8. The browser vendors that wrote the automation-transparency rules quietly stopped enforcing them. Any bypass or detection strategy pivoting on these flags should treat them as unreliable. See the Innovation Feed card "The Vendors That Wrote the Detection Rules" for details.

Once your TLS passes, the page loads its anti-bot script. This is a 500KB+ obfuscated interrogation that runs dozens of tests in parallel.

Most stable signal · GPU dependent
Canvas + WebGL Fingerprinting
The page draws invisible shapes, gradients, and text using canvas.getContext('2d') then calls canvas.toDataURL(). The exact pixel output varies by:

, GPU manufacturer and model (NVIDIA vs AMD vs Intel)
, Driver version and sub-pixel rendering
, OS-level font rendering (Windows ClearType vs macOS CoreText)
, Canvas size and DPI scaling

A headless Chromium with no GPU produces a software-rendered canvas with a known hash. Botaaurus and CloakBrowser spoof this at the C++ level by injecting slight noise into the pixel values before toDataURL() returns, enough to vary the hash while remaining visually identical.
GPU vendor string · Renderer string
WebGL Fingerprinting
WebGL exposes the GPU through gl.getParameter(gl.RENDERER) and gl.getParameter(gl.VENDOR). Real Chrome returns something like ANGLE (Intel, Intel(R) UHD Graphics 620 Direct3D11 vs_5_0 ps_5_0).

Headless Chrome returns a generic string or crashes on WebGL entirely. Anti-bots cross-reference: if WebGL says "Intel UHD 620" but Canvas hash shows software rendering, that's a contradiction, you're flagged.

WebGL extensions list is also fingerprinted. Real GPUs expose 30–40 extensions. Software renderers expose a different subset. The exact combination is GPU-specific and stable across sessions.
Deterministic · Hard to spoof
AudioContext Fingerprinting
The page creates an AudioContextgenerates a sine wave through an OscillatorNoderuns it through a DynamicsCompressorNodeand reads the output buffer values. The floating-point output depends on:

, CPU architecture (x86 vs ARM floating-point precision)
, Operating system audio stack
, Audio driver implementation

Headless environments often return 0.0 across the buffer (no audio context), or a software-emulated value that differs from hardware. CloakBrowser patches this at the Chromium C++ audio rendering layer.
Runtime patches exposed · 2026 standard
Function.toString() Detection
This is why playwright-stealth fails against Kasada in 2026.

When JS patches a native function, for example, navigator.webdriverit replaces the getter with a custom function. Calling Function.prototype.toString.call(getter) on the patched function returns function () { [custom code] } instead of function () { [native code] }.

Kasada specifically tests dozens of native functions this way. playwright-stealth patches them in JavaScript, so toString() reveals the patch. PatchRight fixes this at the Python source levelbefore Chrome even starts. There's no JS to inspect.
The harvest-and-replay threat (Castle Research, April 2026): Real canvas hashes from real Macs are now commercially traded. Services like Bablosoft's PerfectCanvas render canvas on a real remote GPU and inject the result into headless sessions. A "passing" canvas hash is not proof of a real browser, it may be a replayed hash from a legitimate device. Detection systems are responding by pairing canvas probes with harder-to-replay signals: WASM SIMD CPU timing, behavioural Bezier-curve physics, and controlled variability in their own probe scripts. Full report.
Akamai specific · 60 probes in 2026
Chrome Extension Probing (Akamai)
Akamai's sensor.js fetches 60 known Chrome extension resource URLs using fetch('chrome-extension://[id]/manifest.json'). Real Chrome browsers have at least a few extensions installed (ad blockers, password managers, etc.).

A headless browser returns net::ERR_FAILED on all 60 requests simultaneously, a statistically impossible result for a real user. The extension IDs probed include:

cjpalhdlnbpafiamejdnhcphjbkeiagm (uBlock Origin)
hdokiejnpimakedhajhdlcegeplioahd (LastPass)
nngceckbapebfimnlniiiahkandclblb (Bitwarden)

Fix: CloakBrowser loads real extension profiles. You install 1Password or Bitwarden into it so some probes return real manifest data.
CDP timing leaks · Protocol signals
Headless / CDP Detection
Beyond navigator.webdriverCDP-controlled browsers expose themselves through subtler signals:

Timing: CDP's Runtime.enable command leaves a timing gap between page parse and script execution that doesn't exist in real Chrome.
Execution context: window.cdc_adoQpoasnfa76pfcZLmcfl_Array and similar artifacts left by ChromeDriver are checked.
Permission API: Real Chrome returns realistic permission states. ChromeDriver returns defaults inconsistent with a "normal" browser.
Plugins: Headless Chrome has zero plugins. Real Chrome always has at least the PDF viewer plugin.

Camoufox's solution: Uses Mozilla's Juggler protocol, which sits below CDP entirely, none of these artifacts exist.

Layer 2.5, WebAssembly Fingerprinting: The Layer Below Your Stealth Browser

Build-time leak · Nobody patches this
Hyphenation Dictionary Detection
Chromium needs a hyphenation dictionary bundled at build time on Windows and Linux (Android and macOS handle it at OS level). Most people forking Chromium don't know this. The benefit for detection: many stealth Chromium forks literally cannot hyphenate words, and that is visible from JavaScript.

The probe: set hyphens: auto on a narrow container, render a known word like "hyphenation", read the rendered width or screenshot via Canvas. A real Chrome on Windows produces hy-phen-ation. A custom fork without the dictionary produces no break, or the wrong break.

Affected stealth browsers: anything built from a custom Chromium source that skipped the hyphenation step, which is most of them. Real CloakBrowser and properly-built forks include it, hand-rolled patches usually don't.

Mitigation: confirm your build ships the dictionary for every language you claim to support, or run a real Chrome binary under XVFB. Verify with the live PoC: joe12387.github.io/hyphenation-dictionary-poc · github source
CPU fingerprinting · DataDome internal research
WASM SIMD probes the CPU itself
WebAssembly SIMD (Single Instruction Multiple Data) gives browsers access to 128-bit vector operations that map directly to CPU instructions. Anti-bots ship tiny WASM modules that execute SIMD ops in deterministic patterns and time them. The results reveal vector register width, NEON vs SSE vs AVX availability, and microarchitecture quirks unique to the CPU model.

Why this matters: stealth browsers like Camoufox, CloakBrowser, PatchRight patch what the browser reports. WASM SIMD probes the actual CPU. A real Mac with M2 chip can't be spoofed to look like an Intel laptop because the SIMD timing fingerprint is generated by the silicon, not by the browser.

Source: Anthony Manikhouth (DataDome bot detection engineer), blog.azerpas.com, May 2026.
High-resolution timing · The enabling primitive
SharedArrayBuffer via WASM gives 17× timer precision
Chrome floors performance.now() at 100µs on non-isolated pages to prevent Spectre-style timing attacks. But one line of JavaScript breaks that: new WebAssembly.Memory({shared:true}).buffer returns a real SharedArrayBuffer on any page, no special headers required.

Paired with a MessageChannel ping-pong loop in a hidden iframe driving Atomics.add(), you get a counter incrementing at 100,000 Hz, distinguishing steps around 6µs. That's 17× finer than the timer Chrome intends you to have.

Why anti-bots love this: micro-timing patterns (canvas render time, JS jitter, animation frame variance) differ between humans and bots at sub-millisecond scale. WASM shared memory makes that measurable on every page, not just cross-origin-isolated ones. Reported to Chrome as crbug 40057687, marked Won't Fix.

Source: Manuel (brokenbrowser.com).
Bypass implications
Why your stealth browser still leaks
WASM fingerprinting sits in a blind spot of most stealth tools. The signal flow:

1. Anti-bot ships a WASM module with SIMD ops and a high-resolution timer built from WebAssembly.Memory({shared:true}).
2. The module runs natively, no JS hooks to intercept, no Function.toString() traces to leak.
3. CPU microarchitecture + timing patterns are POSTed back as part of the bot scoring payload, often alongside the canvas hash.

What this defeats: Camoufox (Firefox C++ patches), CloakBrowser (49 Chromium patches), PatchRight, undetected-chromedriver, Nodriver, Pydoll. All of them patch JS APIs and binary internals, but none patches the WASM execution layer.

What still works: real hardware diversity. Different physical machines produce different SIMD fingerprints naturally. The future of stealth scraping is less about better lies and more about real hardware in real consumer locations, which is exactly what residential proxies on real ISP IPs already approximate.
CVE-2026-6770 · April 2026 · Process memory leak
IndexedDB Iteration Order: The Fingerprint Nobody Patched
Firefox stored IndexedDB database names using internal UUID mappings in a global hash table shared across all origins within the same browser process. When a site calls indexedDB.databases(), the names come back in hash table iteration order, which is deterministic and stable for the lifetime of that process. Two unrelated sites see the same ordering and can use it to silently link a user's activity across domains — no cookies, no shared storage, no user interaction required.

The fingerprint persisted across reloads, new private windows, and even Tor Browser's "New Identity" resets. Only a full browser restart cleared it. Fixed in Firefox 150 / Tor Browser 15.0.10 (April 21, 2026).

Scraper implication: If you run multiple scraping identities inside the same browser process (shared Camoufox instance, same Firefox PID), an anti-bot can correlate them using this ordering as a stable session token — regardless of proxy rotation, cookie isolation, or fingerprint patching. The signal is below every stealth layer.

Rule: Isolate scraping identities at the process level, not just the profile level. One identity = one browser process. Verify your Camoufox build is on Firefox 150+.
Ref: CVE-2026-6770 · mfsa2026-30 · SecurityAffairs writeup

Layer 3, Network Identity: The Five Vectors That Must Agree

This is the layer most people underinvest in. Beginners pour effort into header spoofing and fingerprint patching while running through a flagged IP, and then wonder why nothing works. It is backwards. If your IP reputation is bad, no amount of header spoofing will save your requests, the request is scored down before your carefully crafted headers are ever read. Infrastructure beats code here: a plain HTTP client on a clean residential IP routinely outperforms a perfectly patched browser on a flagged datacenter IP. Get the network identity right first, then worry about everything above it.
Primary signal
IP Reputation & ASN
Anti-bots check your IP against ASN databases. AWS (AS16509), GCP (AS15169), Azure (AS8075) are immediately flagged. DigitalOcean, Linode, Vultr, all known. Even residential proxy networks from DataCenter IPs in the 24.105.x.x range are flagged if the ASN is a known proxy provider. Genuine ISP residential or 4G carrier IPs are the only reliably clean option.
Browser API · Often overlooked
WebRTC IP Leak
JavaScript can query WebRTC ICE candidates which reveal your real local and public IP, even through a proxy. If your browser has a US proxy but WebRTC reveals a Pakistani local address, or the ICE candidate is from a different subnet than the HTTP request IP, that's an immediate flag. Camoufox's geoip=True aligns WebRTC candidates with the proxy exit country.
All five must agree
The Coherence Test
Anti-bots run a coherence check across: IP country, timezone, Accept-Language, WebRTC candidate, DNS resolver location. A US proxy with Accept-Language: ur-PK fails immediately. All five must tell a consistent geographic story. This is why setting geoip=True in Camoufox is critical, it auto-configures all five to match the proxy's exit country.

Layer 3.5, DOM Honeypots: The Trap Doesn't Care About Your Fingerprint

Hidden DOM elements
Honeypot Fields and Links
Invisible form fields and hidden links that humans never see but bots fill in or click. Triggered = bot detected = IP banned. Common patterns: display:none, visibility:hidden, opacity:0zero-dimension elements, off-screen positioning, fields with tabindex="-1"or links placed after the closing </body> tag.
Data poisoning
Fake Data Served to Suspected Bots
More dangerous than blocking, sites detect a scraper and silently serve different prices, fake reviews, wrong stock counts. You think you're scraping successfully but your dataset is corrupted. Defence: compare scrapes from 2+ different IP profiles for the same URL. Mismatched data = poisoning. Always check element visibility (getBoundingClientRect()) before interacting.

Layer 4, Behavioural ML: You Can't Fake Being Human

Physics-based · Gaussian jitter
Mouse Movement Curves
Human mouse movements follow Bezier curves with Gaussian noise applied to velocity. The mouse decelerates as it approaches a target (Fitts's Law), overshoots slightly, then corrects. Scrapers that click elements directly (teleporting the mouse to x,y) create a trajectory signature that's statistically impossible for a human. DataDome's 35-signal behavioural model catches this immediately. Botasaurus generates physically realistic curves with randomised velocity profiles.
Sub-millisecond precision · ML scored
Timing Analysis
Transformer ML models trained on millions of sessions measure: time between page load and first interaction, scroll acceleration curves, inter-keystroke timing variance, navigation dwell time, and micro-timing of JS event handlers at <1ms precision. A scraper that immediately calls document.querySelector() after DOMContentLoaded looks nothing like a human who reads the page for 2.3 seconds first. Warm-up navigation (visiting homepage before target) significantly improves behavioural scores.
The story so far: You now understand the full detection stack, TLS fingerprints at the network layer, JS interrogation in the browser, IP reputation checks per request, and ML behavioural analysis across the session. The next sections show you exactly which anti-bot vendors use which combination of these layers, and the specific bypass strategies for each.

Now you know the four detection layers. Every vendor below is just a different weighting of those same four signals, some prioritise TLS, others behaviour, others network identity. Knowing the layer tells you which tool to pick. Here are the six walls.

03 The vendors

Six companies built the walls.
Here's every key.

Each vendor applies the detection layers differently, different weights, different signals, different architectures. What bypasses Cloudflare has zero effect on Kasada. You need to know exactly which wall you're facing before you choose a tool.

Step 0, Before anything else

Identify which anti-bot you're facing

Wrong strategy on the wrong vendor wastes hours. Before writing a single line of code, spend 30 seconds identifying exactly what's protecting the target.

1 Wappalyzer Chrome Extension Install free ↗

Visit the target site, click the Wappalyzer icon in your toolbar. It instantly shows all detected technologies, including the anti-bot vendor. Shows Akamai, Cloudflare, DataDome, PerimeterX, Kasada and more with a single click.

2 Check response cookies

Open DevTools → Application → Cookies. Match any cookie name to identify the vendor. Multiple vendors can run on the same site. For CLI scanning at scale: wafw00f https://target.com identifies WAF + anti-bot vendor in one command.

3 Check response headers

DevTools → Network → any request → Response Headers. Look for x-datadome, server: cloudflare, x-akamai-request-idor challenge redirect URLs containing vendor names.

🔍 Wappalyzer

Free Chrome + Firefox extension. One click on any site shows:

  • Anti-bot / security vendor
  • CDN provider
  • CMS, framework, analytics
  • Server technology
Install Wappalyzer Free ↗ Firefox version ↗
01/06 · Airlines · Banks · ~30% Fortune 500
Bot Manager v3+ injects sensor.js (~512KB, fully obfuscated) into every protected page. Unlike Cloudflare which checks at CDN edge, Akamai runs its full fingerprint suite inside your browser via this script. It collects 500+ signals over multiple requests, trust accumulates across the session, not just on the first hit. The critical 2026 signal: 60 chrome-extension:// URL probes. Zero passing = instant bot score regardless of all other signals. JA4+ is checked at EdgeWorker before HTML is served.
_abck cookie bm_sz 60 ext probes Battery API Multi-req scoring
Bypass strategy
Step 1: Check for GraphQL/XHR API first, a direct endpoint bypasses HTML anti-bot entirely
curl_cffi impersonate="chrome124" handles TLS + HTTP/2 layer
CloakBrowser with 49 C++ patches handles sensor.js interrogation
Load Bitwarden + 1Password extensions to pass 60 extension probes
ISP/static residential proxy, never rotate mid-session (trust accumulates)
Homepage warm-up → 2–3s human dwell → scroll → navigate to target
Script size
~512KB
Re-obfuscated per rotation
Ext probes
60
Zero passing = instant block
Fortune 500
~30%
Retail, airlines, finance
Scoring
Multi-req
Trust builds across session
02/06 · 20% of all internet traffic · 200+ countries
Cloudflare's uniqueness is infrastructure-level deployment. JA4 is computed in a Rust crate running on every Cloudflare edge node, your request is fingerprinted before it reaches any application server. The ML bot score (1–99) is trained on Cloudflare's view of 20% of all internet traffic, giving it an unmatched baseline for what "real" browsers look like. Turnstile (their CAPTCHA replacement) submits a 79-parameter POST including Canvas hash, font measurements, SHA-256 proof-of-work, and TEA-encrypted timing data.
cf_clearance __cf_bm JA4 Rust edge Turnstile 79 params ML score 1–99
Bypass strategy
Origin IP bypass: check SecurityTrails DNS history, many sites had Cloudflare added later, origin IP is in old A records
Camoufox with geoip=True, 100% pass rate Mar 2026 on Instagram, Reddit, X, LinkedIn
Scrapling's StealthyFetcher solves Turnstile natively and automatically
Turnstile HTTP bypass possible: solve the PoW + Canvas hash without a browser in ~0.27s
Camoufox uses Juggler (not CDP), zero CDP timing artifacts that Cloudflare's ML scores heavily
Web coverage
20%
All internet traffic
Turnstile params
79
Canvas + PoW + TEA crypto
Camoufox
100%
Pass rate Mar 2026
ML training
Global
20% of all traffic
03/06 · 5 trillion signals/day · 1,200+ clients
DataDome's architecture is fundamentally different from the others: it deploys 85,000 separate ML modelsone per protected site. There is no universal bypass. What works on Grainger.com may not work on Le Monde. It runs at the application server level (not CDN), so origin IP bypass is impossible. The WASM boring_challenge is a Rust-compiled state machine that cannot be emulatedit requires actual browser execution to produce valid tokens. IP reputation alone accounts for 25–30% of the total trust score.
datadome cookie WASM boring_challenge Picasso device FP 35+ behavioural 85K per-site models
Confirmed bypass, Grainger.com ✓
Always try first: find __NEXT_DATA__ in HTML source, Grainger had 110KB of product data in it, bypassing DataDome entirely
curl_cffi chrome124 + residential proxy → confirmed 200 OK (Grainger.com)
Mobile carrier IP (T-Mobile, Vodafone 4G), highest trust score, hardest to flag
Camoufox + geoip=Truealigns all 5 identity vectors with proxy exit country
2ms real-time response means every request is independently scored
ML models
85,000
One per protected site
Response
2ms
Real-time, app server
IP weight
25–30%
Of total trust score
Universal bypass
None
Per-site models
04/06 · HUMAN Security · 3 billion devices
After merging with HUMAN Security, PerimeterX gained the most powerful network effect in anti-bot. It verifies 15 trillion interactions per week across 3 billion devices. The critical risk: get detected on any one of 29,650+ protected sites and your fingerprint is flagged across the entire network. Nike, Walmart, Zillow, StubHub all share reputation data. Its 5-vector unified score (TLS + IP + HTTP headers + JS fingerprint + Behaviour) requires all five to pass simultaneously, fixing only one vector has zero effect.
_px3 cookie _pxde cookie 5-vector score 29,650 site network Human Challenge
Bypass strategy
All 5 vectors must pass simultaneouslyCamoufox + residential proxy addresses all of them
Generate a fresh fingerprint per session, never reuse fingerprints across different target domains
SeleniumWire can intercept the _px3 token generation flow for token replay
Scrapfly's ASP flag handles all 5 layers automatically at managed API level
Never use burned IPs, the network effect means cross-site reputation
Sites
29,650+
Nike, Walmart, Zillow
Weekly verif.
15T
3B devices/month
Vectors
5/5
All must pass
Network effect
Global
Reputation shared
05/06 · No CAPTCHA · Gatekeeper proxy architecture
Kasada operates as a gatekeeper proxyevery request flows through it before reaching origin. Its JavaScript (ips.jsrenamed polymorphically each deployment) issues proof-of-work challenges that require real CPU cycles and browser APIs to solve. There are no CAPTCHAs, failures are silent 403s or 429s with no explanation. The critical 2026 fact: Kasada specifically fingerprints playwright-stealth by calling Function.prototype.toString() on patched native functions. The patch signatures are catalogued.
x-kpsdk-ct x-kpsdk-cd ips.js PoW polymorphic JS toString() inspection
Bypass strategy
Never use playwright-stealthKasada has its toString() signatures catalogued and blocks it outright
PatchRight patches at Python source level, nothing in the JS runtime to inspect via toString()
SeleniumBase UC mode, removes webdriver flag and auto-handles PoW challenges
Residential proxy essential, datacenter IPs receive near-zero trust regardless of browser
PoW tokens are single-use, never replay, always generate fresh per request
Block style
Silent
403 no explanation
playwright-stealth
Detected
Catalogued signatures
Challenge
JS PoW
Real CPU required
JS file
Polymorphic
Renamed each deploy
06/06 · $1 billion acquisition · Most sophisticated
F5 acquired Shape Security for $1 billion in 2020and the price reflects what they built. Shape runs a custom JavaScript virtual machine. The bytecode that executes in the browser is not standard JavaScript, it's a proprietary instruction set that you cannot reverse-engineer with standard tooling. Session tokens expire in minutes. The challenge payload is re-generated with every rotation. For production scraping at scale, DIY bypass is economically irrational, the engineering cost of maintaining a bypass exceeds the cost of Bright Data's API within weeks.
reese84 cookie TS cookie custom JS VM minute-cadence rotation $rsc= params
Bypass strategy
First: check if mobile app uses a weaker backend, Shape is often only on the web frontend
Only reliable option at scale: Bright Data (98.44%) or Zyte (93.14%) managed APIs
DIY reverse engineering: deobfuscate VM bytecode, takes weeks per rotation
Cost-justify: >2 days/month of maintenance time → managed API is cheaper
The custom VM produces tokens that can be replayed for a few minutes, session pooling can reduce API costs
Acquisition
$1B
F5 Networks 2020
Token expiry
Minutes
Tight rotation cadence
VM type
Custom
Proprietary bytecode
DIY viability
None
Use managed API
Forter
Fraud / Behavioural
Focuses on behavioural analysis and device fingerprinting for fraud prevention. Monitors checkout speed, typing rhythm, and device profile. Common on e-commerce checkouts. Bypass: headless browser with randomised timings, diverse residential proxy pool, replay real user interaction sequences.
BehaviouralDevice FPCheckout fraud
Riskified
Fraud / Behavioural
Monitors shopping and payment behaviour alongside device fingerprinting. Flags anomalies in purchase flow, typing patterns, and system details. Bypass: Playwright Stealth with realistic interaction replay, residential proxies, maintain full session cookies across the purchase flow.
BehaviouralDevice FPPayment flows
Imperva Incapsula
WAF · IP reputation · JS challenges
Enterprise WAF used by Fortune 500 financial and government sites. Focuses on IP reputation databases + JavaScript challenges + behavioural analysis. Less aggressive than DataDome on TLS but harsh on flagged IPs. Bypass: residential proxies (datacenter IPs nuked instantly), Camoufox or fortified browser, slow request pacing.
IP reputationJS challengeEnterprise/finance
AWS WAF
Cloud-native · Bot Control · Captcha
Amazon's managed WAF with Bot Control add-on. Three protection levels: Common (signature-based), Targeted (behaviour + JS challenge), Custom rules. Used by AWS-hosted apps. Bypass: rotate residential IPs (Common tier blocks AWS IPs themselves), browser automation for Targeted tier, request rate ≤ 5/sec to avoid trigger thresholds.
AWS-nativeBot ControlCAPTCHA
Anubis
Open-source · PoW · Anti-AI scraper
Self-hosted Web AI Firewall (15k+ stars on GitHub, MIT licensed, written in Go by Xe Iaso/TecharoHQ). Sits as a reverse proxy and issues JavaScript proof-of-work challenges before serving requests. Built specifically against AI scrapers that ignore robots.txt. Used by Codeberg, FFmpeg, the Linux kernel source, Sourcehut, and most non-Cloudflare FOSS projects. Recognisable by its anime "Anubis" mascot illustration during the challenge. Bypass: headless Chromium with JS enabled (it'll solve the PoW naturally, just slower), or persist the verification cookie across requests. Codeberg confirmed in mid-2025 that AI scrapers already learned to solve Anubis challenges, so it slows scraping but doesn't stop a determined operator.
Proof-of-workSelf-hostedAI-targetedFOSS

Quick identification reference

What you seeAnti-botKey cookie/headerDetection method
"Pardon Our Interruption" pageAkamai block_abckWappalyzer · response body
CF-Ray header · Turnstile iframeCloudflare challengecf_clearanceResponse header CF-Ray
JSON with datadome keyDataDome blockdatadomeResponse header x-datadome
_px3 or _pxde setPerimeterX block_px3Cookie inspection
Silent 403 · no bodyKasada silentx-kpsdk-ctResponse headers · ips.js in source
reese84 or TS cookieF5 Shape blockreese84Cookie names · Shape JS reference
Anime mascot "weighing your soul" pageAnubis challengetecharo.lol-anubis-authJS PoW challenge · Anubis HTML title
302 redirect to a virtual waiting roomQueue-It queueQueue-it token cookieX-Queueit-Connector header · queue-it.net redirect
The through-line: Every anti-bot vendor is defending against the same thing, automated access that looks like a machine. The difference is which layer they weight most heavily. Akamai weights browser execution (sensor.js). Cloudflare weights TLS + global ML. DataDome weights per-site behaviour + IP. PerimeterX weights the network effect. Kasada weights PoW + JS integrity. F5 Shape weights token validity via a proprietary VM. The tools in the next section exist as direct countermeasures to each of these specific approaches.

Six walls. Now the tools. Every library below exists as a direct response to one of those six systems, curl_cffi was built because JA4 broke Python's TLS. Camoufox because CDP leaks signal automation. PatchRight because Kasada fingerprints JS patches. The arms race made this arsenal.

05b Field notes

How I approached real-world bypasses

The theory above tells you what anti-bots do. These notes tell you what I did when I hit them on a production job. Each is a full day or two of work distilled to: what I tried, why it failed, what finally worked, and the decision tree I'd use next time.

Read these as snapshots, not recipes. Each case is dated and reflects what worked on a specific target at a specific time. Anti-bot systems are probabilistic and adapt continuously, so the exact stack that worked for me may behave differently for you, on a different target, today. The durable value is the reasoning, not the recipe. See Legal & Reality for the full caveat.
Production bypass · ~1 day No browser · 0 blocks in 500+ requests · 24 req/min sustained

Akamai v3 in 2026: cracking it without a browser

Field notes from a production scraping job. The story of what I tried, why each thing failed, and the exact approach that finally got clean 200 responses with zero browser overhead.

The core problem · _abck ~-1~ won't flip

Akamai's _abck cookie has two states. ~-1~ means unvalidated, full bot score, blocked. ~0~ means validated, trust granted. The cookie is set immediately on any page load, but only flips to ~0~ after sensor.js (a 512KB obfuscated fingerprinting script) executes, collects signals, and POSTs them to /_bm/data.

Signals that matter most: canvas fingerprint (pixel-level hash of GPU-rendered shapes and text), WebGL renderer (exact GPU model via WEBGL_debug_renderer_info), AudioContext (floating-point sine wave through a compressor node), Chrome extension probes (60 chrome-extension:// URLs fetched via fetch(), zero passing = instant bot score), mouse/scroll trajectory physics, and navigator properties cross-checked against the fingerprint.

The kicker: validation is multi-request. Trust accumulates across the session, not just on the first hit.

What failed (and why)
× Attempt 1 — Headless Chrome variants (undetected-chromedriver, Pydoll)
Standard starting point. Tried Chrome headless with undetected-chromedriver (uc) routed through a Comcast ISP proxy. Then switched to Pydoll — CDP automation without the usual webdriver flags. Both behaved identically. _abck set immediately as ~-1~, never flips. Waited 60 seconds, scrolled, dispatched JS mouse events. Nothing.
Why: headless Chrome has no GPU. gl.getContext('webgl') returns null. Sensor.js sees zero WebGL context and assigns maximum bot score before the session even starts.
× Attempt 2 — SwiftShader software GPU
Tried --use-angle=swiftshader --use-gl=angle. WebGL works. Canvas renders. AudioContext works. Renderer: ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) (0x0000C0DE))).
Why: 0x0000C0DE is SwiftShader's device ID, in public lists of virtual GPU IDs. Akamai checks the unmasked renderer against a blocklist. SwiftShader is on it. The canvas hash it produces is also deterministic and known.
× Attempt 3 — Camoufox (Firefox with C++ patches)
Camoufox is excellent for Cloudflare. Real canvas hash, coherent device profile, no CDP artefacts because it uses Mozilla's Juggler protocol. geoip=True aligns WebRTC, DNS, and timezone with the proxy exit country. Set up a session, pointed it at the target, ran a few warm-up requests.
Why: Camoufox patches the browser, not the network. The TLS fingerprint it produces is Firefox, but on this particular Akamai deployment, even Firefox's real JA4 wasn't enough — the IP reputation scoring on my exit IP and the multi-request trust accumulation Akamai uses meant validation never completed. Camoufox does great work where Cloudflare scoring is the gate; here the gate was earlier and harder.
× Attempt 4 — JS prototype patching via CDP
Inject before page load via Page.addScriptToEvaluateOnNewDocument: patch WebGLRenderingContext.prototype.getParameter to return "Intel Iris OpenGL Engine". Patch navigator.platform to "MacIntel", deviceMemory to 8, battery API, chrome.runtime. Result: 2327-byte error page before sensor.js runs.
Why: Akamai's EdgeWorker fires at the TLS layer before HTML is served. JS injection patches don't affect the TLS handshake. The site also detects the timing signature left by Page.addScriptToEvaluateOnNewDocument. The prototype tampering itself is detectable via Function.prototype.toString().
× Attempt 5 — CDP UA override only
Use Network.setUserAgentOverride with full userAgentMetadata to spoof macOS Chrome 148. No JS injection. Same error page.
Why: the UA override changes HTTP headers and what navigator.userAgent returns, but not the TLS ClientHello fingerprint. Akamai's EdgeWorker sees the JA4 hash (still Linux Python automation) and blocks at the network layer before the page loads.
× Attempt 6 — Xvfb virtual display + non-headless Chrome
The hypothesis: headless detection is at the GPU level. Give Chrome a virtual display, it thinks it has a real screen. xvfb-run -a, Chrome launches in headless=False. Pages load fully (1.1MB real HTML, all images, category navigation).
Why: Xvfb has no GPU either. glxinfo shows Mesa software rasterizer. Canvas hash from Mesa llvmpipe is different from SwiftShader but still a known server software renderer, also flagged. _abck stays ~-1~ for 60+ seconds regardless of scrolling.
× Attempt 7 — Inject real Mac canvas hashes via CDP
If the server's canvas hash is flagged, why not inject a real Mac hash? Requires Page.addScriptToEvaluateOnNewDocument again. Same problem as Attempt 3.
Why: the injection itself is the signal, regardless of what values we inject. Akamai detects the patch through CDP timing artefacts and Function.toString() inspection.
The breakthrough · I was fixing the wrong layer

Every failed attempt above tried to fix the browser layer. The fundamental insight: most Akamai-protected sites never reach the deep sensor.js evaluation if the request looks like real Chrome at the network layer first.

Akamai scores in five layers:

Layer 1 · TLS JA4fires before HTML is served
Layer 2 · HTTP/2 SETTINGSHEADER_TABLE_SIZE, WINDOW_SIZE
Layer 3 · ALPN + header orderh2 vs h3, Chrome order
Layer 4 · sensor.jscanvas, WebGL, audio, extensions
Layer 5 · Behaviouralmouse Bezier, scroll timing

Python's requests, httpx, even curl_cffi with a wrong impersonation profile all fail at Layer 1. The JA4 hash doesn't match Chrome 148's actual ClientHello. Fix Layers 1-3 correctly and you often never reach Layer 4.

✓ What worked · a Go library reimplementing Chrome's TLS stack

A Go library, akamai-v3-sensor, reimplements Chrome's exact TLS stack at the C level: cipher suite order, GREASE values, extension ordering, ALPN, HTTP/2 SETTINGS frames, HTTP/3 QUIC parameters. The JA4 fingerprint it produces is indistinguishable from real Chrome 148 because it is Chrome 148's cipher suite, implemented in Go.

// One session, one proxy, one request
s := sensor.NewSession("chrome-148",
    sensor.WithSessionProxy("http://user:pass@comcast-ip:port"),
    sensor.WithSessionTimeout(30*time.Second),
)
resp, _ := s.Get(context.Background(), "https://target-site.com/")
// Status: 200, Protocol: h2, _abck: ~0~ (validated)

// Then GraphQL directly on the same session
gql, _ := s.DoWithBody(ctx, req, bytes.NewReader(payload))
// Status: 200, 30KB product data, zero blocks

No browser process. No GPU. No canvas hash. No sensor.js execution. Just a TLS handshake that matches Chrome 148 exactly because it uses Chrome 148's cipher suites.

Production architecture
Scrapy spider
  → GoProxyMiddleware (urllib, ~35ms round trip)
      → Go HTTP server :8765 (4-session pool)
          → Go TLS library sessions
              → ISP proxy (Comcast AS7015, static residential)
                  → Target site

Session rotation logic: 206 or GenericError triggers the next session in the pool. Three errors on one session triggers a background re-warm (new TLS handshake, new session state). All 4 sessions blocked returns 503; Python middleware waits 5s and retries up to 3× before falling back to curl_cffi.

24 req/min sustained
0 blocks in 500+ requests
0 browser processes
4 session pool
Key takeaways
Canvas fingerprinting cannot be fixed at the JS layer. Patching toDataURL() or getParameter() in JavaScript is detectable via Function.prototype.toString(). The only real fix is at the C++ level, either a real GPU or a library that bypasses the browser entirely.
SwiftShader's 0x0000C0DE device ID is permanently flagged. Don't bother. It's in Akamai's blocklist and the deterministic canvas hash is also known. Same for Mesa llvmpipe.
Page.addScriptToEvaluateOnNewDocument is itself a signal. Akamai's EdgeWorker detects the timing gap left by CDP's Runtime.enable command. The injection runs, but the metadata around it is visible.
The TLS layer is the one that matters first. Fix JA4, HTTP/2, ALPN, and header order before worrying about canvas or WebGL. Most deployments never even reach sensor.js if the TLS fingerprint doesn't match.
A clean ISP proxy IP matters. Comcast AS7015 static residential is what worked. Datacenter IPs fail at the IP reputation layer regardless of TLS quality. Rotating residential proxies break session trust accumulation, Akamai scores per-session not per-request.
Practical decision tree · Akamai in 2026
01 Find the mobile / GraphQL API first. Often zero anti-bot. Same data, no sensor.js. Look for /graphql, /api/v1/, mobile traffic intercepted via HTTP Toolkit.
02 curl_cffi chrome131 + ISP residential proxy. Works on ~60% of Akamai targets where sensor.js scoring is light.
03 Go TLS library (akamai-v3-sensor) + ISP proxy. For targets with heavier sensor.js where curl_cffi's impersonation doesn't pass JA4 at the EdgeWorker.
04 CloakBrowser (49 C++ patches, loads real extensions). For targets requiring a real canvas hash and passing the 60-extension probe. The kill-switch for sites where TLS spoofing alone is not enough.
05 Managed API (Scrapfly, Bright Data). For Bot Manager Premier targets running pixel challenges. Engineering cost exceeds managed API cost.
04 The arsenal

Every tool built to fight
every wall we just described.

Now that you understand the detection stack and the six anti-bot vendors, every library below makes sense in context. curl_cffi exists because of JA4. Camoufox exists because of CDP leaks. PatchRight exists because of Kasada's toString() inspection. The arsenal wasn't built randomly, each tool is a direct countermeasure to a specific detection innovation.

Before the table · pick the right language first

Scraping is no longer Python-only.

Python still dominates the open-source ecosystem (Scrapy, curl_cffi, Camoufox), but the hardest 10% of targets in 2026 reach for Go, TypeScript, or Rust. Here's when each language earns its place, and why mixing them in one pipeline is the production-grade move.

Python Default
Largest ecosystem. Scrapy + curl_cffi + Camoufox cover 80% of targets. Best for data engineers already running pandas, Airflow, dbt downstream.
Use when: default choice, fast prototyping, ML pipelines, when team is Python-native
Key libs: Scrapy, curl_cffi, Camoufox, PatchRight, Crawlee-python, scrapy-stealth
Go TLS & concurrency
Closest language to OS-level TLS control. Akamai-grade JA4 spoofing is a Go specialty. Native goroutines beat asyncio at 10,000+ concurrent connections. Single binary deploys.
Use when: Akamai v3, F5 Shape, TLS fingerprint precision, 10K+ concurrent crawls, edge deployments
Key libs: akamai-v3-sensor, tls-client, colly, surf, rod, cycletls
TypeScript / Node.js
First-class Playwright and Puppeteer. Better browser automation primitives than Python ports. Strongest ecosystem for AI agents and Chrome extension work. Apify's Crawlee was Node-first for a reason.
Use when: browser automation is the bottleneck, AI agents, Computer Use Agents, working with Chrome DevTools deeply, full-stack JS team
Key libs: Crawlee, Playwright (TS), Puppeteer, Stagehand, Browser Use, ScrapingBee SDK, got-scraping
Rust Emerging
Lower-level than Go, even more control over TLS internals and memory. Used where you need both performance and Chrome-level fingerprint precision. 67% fewer tokens than equivalent Python in some benchmarks. Steeper learning curve.
Use when: webclaw, custom TLS work, MCP servers, performance is critical, you already have Rust on the team
Key libs: webclaw, rquest, rnet, scraper, fantoccini
The pragmatic move in 2026:
Run Python for orchestration (Scrapy is still the best framework for crawl logic, queues, deduplication, and ML downstream). Drop down to Go via a sidecar HTTP service only for the requests that need true Chrome JA4 (Akamai v3, F5 Shape). Use Node + Crawlee or Playwright (TS) when the work is genuinely browser-automation-heavy, especially for AI agents. The Akamai case study above shows this exact pattern: Scrapy spider in Python, calling a Go server via urllib for the protected requests only.

Master comparison table, all 73 libraries & tools

Library (click to expand)TypeLangJS renderTLS spoofTLS detailAnti-bot targetMCPStars
curl_cffi HTTPPython Chrome JA4+Akamai, DataDome
⚡ HTTP
Under the hood: libcurl C library with custom TLS patches. Emits exact Chrome/Safari/Firefox TLS ClientHello at the C level, cipher suites, extensions, ALPN, GREASE all match real browsers.
✓ Pros
  • Fastest HTTP option. Pure HTTP speed, no browser overhead
  • Confirmed DataDome + Akamai bypass in 2026
  • Asyncio support via AsyncSession
  • Simple requests-compatible API
✗ Cons
  • No JavaScript execution, useless for JS-rendered pages
  • Cannot solve CAPTCHA or Turnstile challenges
  • TLS fingerprint only, no behaviour or canvas spoofing
Scrapling HTTPPython Chrome TLSCloudflare Turnstile38k
⚡ HTTP
Under the hood: Wraps curl_cffi for stealth HTTP + integrates Camoufox for browser mode. StealthyFetcher uses a real patched Firefox under the hood when needed.
✓ Pros
  • StealthyFetcher solves Cloudflare Turnstile natively
  • Async spider v0.4, pause/resume, per-domain throttling
  • Dual-mode: HTTP for speed, browser for hard targets
  • Active development, 38K stars
✗ Cons
  • Higher complexity than plain curl_cffi
  • Browser mode adds Camoufox overhead when triggered
webclaw HTTPRust Chrome TLSMedium targets
⚡ HTTP
Under the hood: Rust HTTP client with TLS fingerprint spoofing. Emits browser TLS signatures from Rust, fast and low-memory.
✓ Pros
  • Rust speed, very low CPU/memory overhead
  • TLS fingerprinting at Rust level
  • Good for high-volume HTTP scraping
✗ Cons
  • Rust, no Python API
  • Less widespread adoption
  • No JS rendering
httpx HTTPPython NoneUnprotected only
⚡ HTTP
Under the hood: Modern Python HTTP library with async support and HTTP/2.
✓ Pros
  • Async + sync in one library
  • HTTP/2 support unlike requests
  • Type hints, modern API
✗ Cons
  • TLS fingerprint still Python-default, detectable
  • Not as stealthy as curl_cffi without patching
requests HTTPPython NoneUnprotected only52k
⚡ HTTP
Under the hood: Pure Python HTTP library. Sends HTTP/1.1 requests with standard Python TLS.
✓ Pros
  • Simple API, universally known
  • Synchronous, easy to debug
✗ Cons
  • TLS fingerprint is instantly detectable (Python urllib3)
  • No async, slow for concurrent scraping
  • No anti-bot capability
tls-client HTTPGo/Py Chrome/Firefox TLSAkamai, DataDome
⚡ HTTP
Under the hood: Go/Python wrapper around a Go TLS client that mimics browser fingerprints. Predecessor to cycle-tls.
✓ Pros
  • Python bindings available
  • Bypasses JA3/JA4 fingerprinting
  • Lighter than curl_cffi
✗ Cons
  • Less actively maintained than curl_cffi
  • No JS rendering
  • Binary dependency
Playwright 🌐BrowserPy/JS CDP (detectable)Medium (CDP leaks)68k
🌐 Browser
Under the hood: Chromium DevTools Protocol (CDP). Microsoft-maintained. Drives real Chromium, Firefox, or WebKit browsers over CDP socket.
✓ Pros
  • Best JS execution support, renders any SPA
  • 68K stars, massive ecosystem and docs
  • Cross-browser: Chrome, Firefox, Safari (WebKit)
  • Screenshot, PDF, network intercept built-in
✗ Cons
  • CDP is detectable, needs C++ wrapper (PatchRight/Camoufox)
  • Heavy: launches a full browser process per session
  • Slow vs HTTP, ~10× more memory per concurrent task
Camoufox 🌐BrowserPython C++ Firefox JugglerCloudflare 100%, Akamai
🌐 Browser
Under the hood: Forked Firefox with C++ binary patches to Juggler protocol (below CDP). Patches navigator, canvas, WebGL, fonts, window.chrome at binary level.
✓ Pros
  • 100% Cloudflare pass rate as of March 2026
  • geoip=True aligns all 5 identity vectors automatically
  • Below-CDP, invisible to JS-level detection
  • Async context manager, drop-in playwright replacement
✗ Cons
  • Firefox only, no Chrome/Safari
  • Heavier than curl_cffi
  • Occasional site-specific quirks with Firefox fingerprint
⚠ CVE-2026-6770 — Process-Level Fingerprint Leak (patched Firefox 150) Firefox below v150 returned IndexedDB database names in hash table iteration order rather than sorted order. Because the hash table is shared across all origins within the same browser process, the ordering became a stable, high-entropy process-lifetime fingerprint — consistent across tabs, sites, private windows, and even Tor Browser's "New Identity" resets. Anti-bot systems could use this to correlate multiple scraping identities running in the same browser process, regardless of proxy rotation or profile switching.

Fix: Use Camoufox built on Firefox 150+ (patched April 2026). Verify your version.
Scraper lesson: Always isolate identities at the process level, not just the profile level. Multiple sessions in one browser process can be correlated through memory-state artifacts like this even when fingerprint patching is otherwise perfect.
Ref: CVE-2026-6770 · mfsa2026-30 · Fixed Firefox 150 / Tor Browser 15.0.10
CloakBrowser 🌐BrowserPython 49 C++ patchesAkamai, reCAPTCHA v3 0.9
🌐 Browser
Under the hood: 49+ C++ binary patches to Chromium itself. Patches webdriver, chrome object, plugins, permissions, WebGL, Canvas, AudioContext, and extension probe responses at the C++ level, not JavaScript. Repo: github.com/CloakHQ/CloakBrowser.
✓ Pros
  • reCAPTCHA v3 score 0.9, the highest of any tool I have tested
  • Passes Akamai's 60-URL extension probe (loads real 1Password / Bitwarden / LastPass profiles)
  • Real extension fingerprint database built-in, no manual setup
  • C++ level patches survive Function.prototype.toString() inspection (the kill-switch for JS stealth tools like puppeteer-stealth and patchright)
  • Solves the hard problems Camoufox and PatchRight cannot: canvas hash at the C++ rendering layer, AudioContext at the audio pipeline layer, real extension probe responses
  • Now open source on GitHub, active development
✗ Cons
  • Higher resource cost than HTTP-only tools (200MB+ per instance)
  • Chromium only, no Firefox variant
  • Newer than Camoufox, smaller community
  • Overkill for sites that curl_cffi + ISP proxy already handle
PatchRight 🌐BrowserPython Py source patchesKasada, Cloudflare
🌐 Browser
Under the hood: Patches Playwright Python source files at install time. Removes CDP signatures, webdriver property, and stealth tells from the JS layer.
✓ Pros
  • Open source, free, Kasada bypass confirmed
  • Drop-in Playwright replacement, zero API changes
  • Patches JS layer without C++ recompilation
✗ Cons
  • JS-level patches only, determined adversary can detect at binary level
  • Less robust than Camoufox on Cloudflare 5-second challenge
  • Requires Playwright to be installed first
Puppeteer 🌐BrowserNode CDP (detectable)Medium targets89k
🌐 Browser
Under the hood: Node.js CDP driver for Chromium. Google-maintained. The original headless browser automation library.
✓ Pros
  • 89K stars, largest ecosystem
  • Native Google product, Chromium compatibility guaranteed
  • Good for CI/CD screenshot and PDF generation
✗ Cons
  • CDP is easily detectable (webdriver=true, window.chrome absent)
  • Node.js only, no Python
  • No anti-bot stealth built-in
Selenium 🌐BrowserMulti webdriver=trueWeak (legacy)29k
🌐 Browser
Under the hood: WebDriver protocol (W3C standard). Drives any browser via standardised JSON protocol. The original browser automation framework.
✓ Pros
  • Multi-language: Python, Java, C#, Ruby, JS
  • Supports all browsers including IE and Safari
  • Huge ecosystem, well-documented
✗ Cons
  • navigator.webdriver=true is trivially detectable
  • Slowest option, WebDriver adds round-trip latency
  • Requires ChromeDriver binary management
SeleniumBase UC 🌐BrowserPython UC removes WD flagKasada, general stealth10k
🌐 Browser
Under the hood: SeleniumBase with undetected-chromedriver mode. Patches Chrome binary to remove webdriver flag and CDP signatures.
✓ Pros
  • UC mode removes webdriver=true flag
  • Passes basic Cloudflare and PerimeterX
  • Built-in test framework, good for QA teams
✗ Cons
  • Not as strong as Camoufox/PatchRight on hard targets
  • Chrome binary patches can break on updates
  • Slower than Playwright equivalent
Selenium-Driverless 🌐BrowserPython CDP no WebDriverMedium targets
🌐 Browser
Under the hood: Direct CDP connection without ChromeDriver binary, no webdriver flag set. Async Python API.
✓ Pros
  • No ChromeDriver binary needed
  • No webdriver=true flag
  • Async Python native
✗ Cons
  • Newer, less battle-tested than nodriver
  • Chrome only
  • Some CDP signatures still detectable
nodriver 🌐BrowserPython Raw CDP asyncMedium targets
🌐 Browser
Under the hood: Controls Chrome via its internal DevTools socket without using CDP's standard automation flag. Chrome doesn't know it's being driven.
✓ Pros
  • Chrome does not set automation flags
  • Passes many sites that detect standard CDP
  • Lightweight, lower overhead than full Playwright
✗ Cons
  • Relatively new, less battle-tested
  • Python only
  • Some sites still detect via other JS signals
pydoll 🌐BrowserPython Async CDPMedium targets
🌐 Browser
Under the hood: Pure Python browser automation using Chrome DevTools Protocol directly. No external driver.
✓ Pros
  • No ChromeDriver dependency
  • Fast startup, no driver process
  • Pure Python, easy to install
✗ Cons
  • CDP still potentially detectable
  • Less mature than Playwright
  • Smaller community
Botright 🌐BrowserPython CAPTCHA solvingCAPTCHA targets
🌐 Browser
Under the hood: Playwright wrapper focused on CAPTCHA solving and stealth. Uses AI to solve CAPTCHAs during automation.
✓ Pros
  • Auto-solves reCAPTCHA and hCAPTCHA inline
  • Stealth patches on top of Playwright
  • Good for CAPTCHA-heavy targets
✗ Cons
  • Heavier than raw Playwright
  • CAPTCHA AI may be rate-limited
  • Less control over fingerprinting
Botasaurus 🌐BrowserPython Gaussian mouseDataDome behaviour
🌐 Browser
Under the hood: Playwright wrapper that adds Gaussian mouse movement, realistic typing, scroll physics, and session management.
✓ Pros
  • Gaussian mouse curves, passes behavioural ML checks
  • Handles DataDome behavioural scoring
  • Session persistence and rotating profiles built-in
✗ Cons
  • Browser-based overhead
  • Overkill for targets without behavioural analysis
  • Less control than raw Playwright
rayobrowse 🌐BrowserPy/Docker Real device FP DBHard targets
🌐 Browser
Under the hood: Docker-based stealth Chromium browser from Rayobyte. C++ level patches (not JS-level), exposed via CDP so Playwright/Puppeteer/Selenium can connect natively. Self-hosted = free and unlimited; managed Cloud version available.
✓ Pros
  • Free and unlimited self-hosted (Docker), Cloud version managed
  • C++ level patches survive Function.toString() inspection
  • Coherent device profile: UA, WebGL, Canvas, AudioContext, fonts all match
  • Native CDP, drop-in for Playwright/Puppeteer/Selenium
  • Used by Rayobyte to scrape millions of pages/day in production
✗ Cons
  • Still in beta, results vary by target site
  • Windows + Android profiles strongest, macOS/Linux less mature
  • Closed source (license restricts certain organizations)
  • Canvas/WebGL FP coverage still evolving
undetected-chromedriver 🌐BrowserPython Removes WD flagMedium targets5k
🌐 Browser
Under the hood: Patches ChromeDriver binary to remove webdriver=true and CDP automation flags at binary level.
✓ Pros
  • Removes most obvious webdriver signals
  • Simple: just replace webdriver.Chrome with uc.Chrome
✗ Cons
  • Chrome binary patches break on updates frequently
  • Not as robust as Camoufox on modern Cloudflare
  • Maintenance has slowed
⭐ Scrapy FrameworkPython Via curl_cffi mwMedium (with middleware)52k
⚡ HTTP
Under the hood: Twisted-based async Python framework. Pure HTTP, sends requests, receives responses, parses with XPath/CSS. No browser.
✓ Pros
  • 52K stars, production standard for HTTP scraping
  • Massive ecosystem: scrapy-redis, scrapy-playwright, scrapyd
  • Async by default, hundreds of concurrent requests
  • Mature: pipelines, middlewares, extensions all built-in
✗ Cons
  • No JS rendering by default (need playwright middleware)
  • Pure HTTP, detectable by TLS fingerprint without curl_cffi middleware
  • Steeper learning curve than requests
Crawlee 🌐FrameworkNode/Py Playwright-basedMedium targets15k
🌐 Browser
Under the hood: Apify's unified Node.js framework. Wraps both HTTP (got-scraping) and Playwright/Puppeteer. Handles retries, deduplication, storage.
✓ Pros
  • Dual HTTP+browser mode in one framework
  • 15K stars, actively maintained by Apify
  • Built-in dataset storage, request queue, proxy rotation
✗ Cons
  • Node.js primary (Python port is newer, less mature)
  • More opinionated than Scrapy, harder to customise
  • Heavier dependency footprint
scrapy-camoufox FrameworkPython Camoufox integrationHard targets
⚡ HTTP
Under the hood: Scrapy middleware that routes requests through Camoufox browser for stealth. Best of Scrapy + Camoufox.
✓ Pros
  • Scrapy pipeline management + Camoufox stealth
  • Per-request browser decision (HTTP vs browser)
  • Good for mixed protection targets
✗ Cons
  • Camoufox overhead on browser requests
  • Requires both Scrapy and Camoufox installed
scrapy-nodriver FrameworkPython nodriver integrationMedium targets
⚡ HTTP
Under the hood: Scrapy middleware using nodriver for browser requests, Chrome without CDP flags.
✓ Pros
  • Scrapy framework + Chrome without automation flags
  • Good for Cloudflare-protected targets
  • Use Scrapy architecture you know
✗ Cons
  • nodriver overhead per browser request
  • Less control than raw nodriver
scrapy-stealth FrameworkPython Browser TLS + HTTP/2Cloudflare, Akamaiv0.4 (2026)
⚡ HTTP
Under the hood: Pluggable Scrapy DOWNLOADER_MIDDLEWARE with three drivers: basic + turbo (TLS fingerprint + HTTP/2 impersonation, no browser), and browser (real Chrome via CDP for JS-heavy targets). Per-request engine switching via request.meta["stealth"]. Repo: github.com/fawadss1/scrapy-stealth. Author Fawad ships frequent updates.
✓ Pros
  • Built-in TLS fingerprint spoofing, scrapy-playwright/scrapy-splash/scrapy-selenium do not have this
  • Per-request engine switching: keep light HTTP for easy URLs, browser only for protected ones
  • Built-in proxy + fingerprint rotation (no separate middleware needed)
  • Native Cloudflare and Akamai detection via status + body keyword checks
  • Browser profiles like chrome_147, safari_ios_18_1_1 kept current
  • MIT license, active development (v0.4 May 2026)
✗ Cons
  • Project is new with limited GitHub adoption (low star count)
  • Less battle-tested than scrapy-playwright in production at scale
  • Browser driver 5-15s per page, use selectively for JS-protected URLs only
  • Requires Python 3.11+ and Scrapy 2.15+
Firecrawl AIAPI FIRE-1 engineHard via managed111k
⚡ HTTP
Under the hood: API service that converts any URL to clean Markdown or structured JSON for LLM consumption. FIRE-1 agent for multi-page crawls.
✓ Pros
  • 111K stars, most popular LLM scraping tool
  • Outputs clean Markdown, 67% fewer tokens for LLMs
  • MCP server for Claude/Cursor/LangChain
  • Handles JS rendering and auth flows
✗ Cons
  • API cost at scale
  • Less control over request details vs raw scraping
  • Data goes through third-party servers
Crawl4AI 🌐AIPython Playwright-basedMedium targets60k
🌐 Browser
Under the hood: Local Playwright wrapper optimised for LLM output. Runs locally, converts pages to clean Markdown with BM25 relevance filtering.
✓ Pros
  • Fully local, no API cost
  • BM25 filter reduces LLM context bloat
  • LLM extraction schema definition
  • MIT license, commercial friendly
✗ Cons
  • Playwright overhead per page
  • Less anti-bot bypass than Camoufox
  • No managed infrastructure
ScrapeGraphAI AIPython NL graph pipelineLight protection18k
⚡ HTTP
Under the hood: LLM-powered extraction that builds a graph pipeline from a natural language prompt. Local or API.
✓ Pros
  • Natural language extraction definition
  • Open source, self-hostable
  • Graph pipeline handles multi-step extractions
✗ Cons
  • LLM inference cost/latency per extraction
  • Less deterministic than CSS/XPath selectors
  • Newer, less battle-tested at scale
Jina Reader API AIAPI Built-in renderingMedium targets
⚡ HTTP
Under the hood: REST API: prefix r.jina.ai/ to any URL to get clean Markdown back. Zero setup.
✓ Pros
  • Simplest possible API, one URL prefix
  • Good JS rendering
  • Free tier available
✗ Cons
  • Data goes through Jina servers
  • Less control than local scraping
  • Rate limited on free tier
Steel 🌐AIAPI Docker browserMedium targets
🌐 Browser
Under the hood: Self-hosted browser API with MCP server. AI agents call it as a tool to browse the web.
✓ Pros
  • Self-hosted, data stays local
  • MCP server for AI agent integration
  • Docker deployment
✗ Cons
  • Newer product, smaller community
  • Setup overhead vs managed services
Bright Data ManagedAPI Full enterprise stackAll incl. F5 Shape
⚡ HTTP
Under the hood: 72M+ IP network + scraping API. Managed infrastructure handles anti-bot, JS rendering, proxy rotation.
✓ Pros
  • 98.44% success rate, highest benchmark
  • Covers F5 Shape (only managed service that does)
  • Residential + ISP + datacenter + mobile IPs
  • Dataset marketplace for pre-scraped data
✗ Cons
  • Most expensive option
  • Data goes through third-party
  • Overkill for simple targets
Zyte ManagedAPI Full stackAll targets
⚡ HTTP
Under the hood: Scrapy company's managed scraping platform. Zyte API + AutoExtract for structured data.
✓ Pros
  • #1 Proxyway benchmark 2025
  • AutoExtract returns structured product/article data
  • Built by the Scrapy maintainers
  • Smart proxy rotation built-in
✗ Cons
  • Expensive at scale
  • AutoExtract less flexible than custom extraction
Apify ManagedAPI 10K+ ActorsMedium-hard
⚡ HTTP
Under the hood: 10,000+ pre-built Actors on serverless cloud. Crawlee at core. MCP server for AI agents.
✓ Pros
  • Biggest marketplace of pre-built scrapers
  • MCP server: AI agents call Actors as tools
  • Free $5/mo credit for casual use
  • Crawlee open source available locally
✗ Cons
  • CU pricing can escalate
  • Data goes through Apify cloud
  • Less control over anti-bot approach in Actors
ScrapingBee ManagedAPI Managed renderingMedium targets
⚡ HTTP
Under the hood: Managed scraping API. Handles JS rendering, CAPTCHA, proxies via simple REST call.
✓ Pros
  • Dead simple: one API call, get HTML back
  • Free tier available
  • Handles most modern JS rendering
✗ Cons
  • Less anti-bot strength than Zyte or Bright Data
  • Per-call pricing
  • Less control over request details
SerpAPI ManagedAPI SERP JSON APISearch engine data
⚡ HTTP
Under the hood: Managed API that abstracts Google, Bing, Baidu, Yandex, Yahoo, DuckDuckGo and 80+ other engines behind a single REST endpoint. Returns fully parsed, normalised JSON — organic results, ads, featured snippets, knowledge graphs, local packs, shopping, images, news — without you touching a proxy or a headless browser.
✓ Pros
  • 80+ search engines including Google, Bing, Baidu, Yandex, Yahoo, DuckDuckGo, Google Maps, Google Shopping, Google Scholar
  • Richest parsed output — 15+ SERP element types including AI Overviews, PAA, video carousels, local pack
  • Advanced geo-targeting and device simulation per request
  • Free tier: 100 searches/month, no credit card required
  • Well-documented, widely adopted — largest mindshare in SERP API category
✗ Cons
  • Premium pricing: $75/mo for 5K, $150/mo for 15K searches — expensive vs alternatives like Scrape.do (21x cheaper per request)
  • SERP-specific only, not a general-purpose scraping API
  • Data routed through SerpAPI servers
ScrapeBadger ManagedAPI Smart billing + AI extractCloudflare, DataDome, hard targets
⚡ HTTP
Under the hood: Newer managed scraping API built natively for modern anti-bot stacks. Key differentiator: smart billing — if you enable JS rendering and anti-bot bypass but the target doesn't need them, ScrapeBadger auto-downgrades the request and charges you less. Also ships an MCP server for Twitter/X scraping (profiles, tweets, trends) for AI agent workflows.
✓ Pros
  • Pay-only-for-success model — failed requests don't cost you
  • Smart auto-downgrade: enables anti-bot features only when needed, reducing cost automatically
  • Native Cloudflare Turnstile and DataDome bypass — 99%+ reported success on Zillow, Amazon, LinkedIn
  • AI extraction mode: pass a plain-English prompt, get structured JSON back without writing selectors
  • MCP server for Twitter/X — profiles, tweets, trends for AI agent pipelines
✗ Cons
  • Newer entrant — less battle-tested at scale than Bright Data or Zyte
  • Smaller community and ecosystem vs established providers
  • Data routed through third-party servers
Oxylabs ManagedAPI OxyCopilot AIHard targets
⚡ HTTP
Under the hood: 102M+ IP network with OxyCopilot AI extraction and scraper APIs.
✓ Pros
  • Largest IP pool (102M+)
  • OxyCopilot: AI-powered extraction
  • Strong residential + datacenter options
✗ Cons
  • Enterprise pricing
  • Data through third-party
Browserbase 🌐ManagedAPI Managed browserHard targets
🌐 Browser
Under the hood: Managed Playwright cloud. Run Playwright scripts remotely without managing browser infrastructure.
✓ Pros
  • No browser infra to manage
  • Scales automatically
  • Playwright API unchanged, zero code changes
✗ Cons
  • 42% success rate on anti-bot benchmark (vs 81% Browser Use)
  • Per-session pricing
  • Less stealth than self-hosted Camoufox
chompjs ParserPython N/AParser only
⚡ HTTP
Under the hood: Python library to parse JavaScript objects embedded in HTML pages. Converts JS literals to Python dicts.
✓ Pros
  • Handles malformed JSON that json.loads rejects
  • Extracts __NEXT_DATA__ and embedded JS objects
  • Zero dependencies
✗ Cons
  • Parsing only, not a scraping framework
  • Narrow use case
Parsel ParserPython N/AParser only
⚡ HTTP
Under the hood: Scrapy's HTML/XML parser library. XPath and CSS selectors with a clean Python API.
✓ Pros
  • XPath + CSS in one library
  • Used inside Scrapy, familiar API
  • Faster than BeautifulSoup for selection
✗ Cons
  • Parsing only, no HTTP requests
  • Less beginner-friendly than BS4
BeautifulSoup4 ParserPython N/AParser only10k
⚡ HTTP
Under the hood: Python HTML/XML parser. Wraps lxml or html.parser. Builds a parse tree from raw HTML strings.
✓ Pros
  • Simple, readable API, beginner-friendly
  • Works on any HTML string regardless of source
  • No network requests, pure parsing
✗ Cons
  • Not a scraping framework, needs requests/httpx separately
  • Slow on large documents vs selectolax/lxml
  • No anti-bot capability whatsoever
mitmproxy RE ToolPython N/ARE / intercept37k
⚡ HTTP
Under the hood: Python-based HTTPS proxy. Intercepts, inspects, and modifies HTTP/HTTPS traffic between client and server.
✓ Pros
  • Full request/response visibility and modification
  • Script intercepted traffic with Python
  • Good for understanding anti-bot request patterns
✗ Cons
  • Requires certificate trust on device
  • SSL pinning blocks it on hardened apps
  • For analysis/RE, not production scraping
HTTPToolkit RE ToolAny N/AMobile API intercept
⚡ HTTP
Under the hood: HTTPS intercepting proxy for development and mobile API discovery. Open source.
✓ Pros
  • Intercepts HTTPS without SSL pinning (with rooted device)
  • Beautiful UI for inspecting requests
  • Works with Android emulators via ADB
✗ Cons
  • For analysis only, not for production scraping
  • Requires rooted device for mobile apps
Frida RE ToolPy/JS N/ASSL hooks
⚡ HTTP
Under the hood: Dynamic instrumentation toolkit. Injects JavaScript into running processes. Used to hook native functions and bypass SSL pinning.
✓ Pros
  • Bypass SSL pinning in any Android/iOS app
  • Hook any native function at runtime
  • Essential for mobile app API extraction
✗ Cons
  • Requires rooted/jailbroken device
  • Complex setup, not for beginners
  • App-specific scripts needed per target
rebrowser-patches 🌐BrowserPython Chrome source patchesMedium targets
🌐 Browser
Under the hood: JavaScript patches injected into Playwright/Puppeteer pages to mask automation signals.
✓ Pros
  • Removes navigator.webdriver and CDP signals at JS level
  • Works with any Playwright version
  • Easy to integrate
✗ Cons
  • JS-level only, binary signals still present
  • Less robust than C++ patches
cycle-tls HTTPGo/JS Chrome/Firefox TLSAkamai, DataDome
⚡ HTTP
Under the hood: Node.js/Go TLS client that cycles through browser fingerprints. Sends real JA3 hashes per request.
✓ Pros
  • Node.js TLS fingerprint spoofing
  • Per-request fingerprint rotation
  • Good for JS pipeline scraping
✗ Cons
  • Node.js only, no Python
  • Less robust than curl_cffi on hard targets
GoLogin 🌐BrowserCloud Antidetect profilesHard multi-account
🌐 Browser
Under the hood: Cloud anti-detect browser. Manages browser profiles with unique fingerprints stored in cloud. Multi-account management.
✓ Pros
  • Profile fingerprint management at scale
  • Good for multi-account scraping operations
  • Team sharing of browser profiles
✗ Cons
  • Paid product, cloud-dependent
  • Not suitable for automated pipeline scraping
  • Designed for manual browsing, not scripted crawling
Multilogin 🌐BrowserCloud Antidetect profilesHard multi-account
🌐 Browser
Under the hood: Commercial anti-detect browser with managed profile fingerprints. Team collaboration on browser profiles.
✓ Pros
  • Professional multi-account management
  • Managed fingerprint database
  • Team profile sharing
✗ Cons
  • Very expensive
  • Designed for manual use, not automated crawling
  • Data in cloud
ScraperAPI ManagedAPI Full stackAll incl. Walmart
⚡ HTTP
Under the hood: Simple proxy rotation + JS rendering API. Handles geo-targeting and header rotation.
✓ Pros
  • Simple integration, just prepend URL
  • Free tier with 1000 calls/mo
  • Geo-targeting built in
✗ Cons
  • Weaker on hard anti-bot targets
  • Basic anti-bot handling vs Zyte/Bright Data
Decodo ManagedAPI Full stackAll targets
⚡ HTTP
Under the hood: Smartproxy's new brand. Residential, datacenter, and mobile proxy network.
✓ Pros
  • Affordable residential proxies
  • Pay-as-you-go pricing
  • Good for mid-scale scraping
✗ Cons
  • Less powerful than Bright Data on hard targets
  • Smaller IP pool
CapSolver CAPTCHAAPI N/AreCAPTCHA/hCaptcha
⚡ HTTP
Under the hood: AI-powered CAPTCHA solving service. Uses computer vision to solve reCAPTCHA v2/v3, hCAPTCHA, Cloudflare Turnstile.
✓ Pros
  • Solves reCAPTCHA v3, hCAPTCHA, Turnstile, ImageCAPTCHA
  • Fast: under 10 seconds for most CAPTCHA types
  • API-based, works with any language
✗ Cons
  • Cost per solve (~$0.001–0.002)
  • reCAPTCHA v3 score may be low vs C++ browser
  • Solving is symptomatic, better to avoid triggering CAPTCHA
2captcha CAPTCHAAPI N/AAll CAPTCHA types
⚡ HTTP
Under the hood: Human + AI hybrid CAPTCHA solving service. One of the oldest in the market.
✓ Pros
  • Solves almost any CAPTCHA type including custom ones
  • Human fallback for unusual CAPTCHAs
  • Large API ecosystem
✗ Cons
  • Slowest option, human solving adds latency
  • Cost per solve
  • Less automated than CapSolver
Anti-Captcha CAPTCHAAPI N/AreCAPTCHA/image
⚡ HTTP
Under the hood: Human + AI CAPTCHA solving service. Competitor to 2captcha.
✓ Pros
  • Solves all major CAPTCHA types
  • Competitive pricing
  • API compatible with 2captcha
✗ Cons
  • Human solving latency
  • Cost per solve
  • Better to avoid triggering CAPTCHA in the first place
Scrapyd FrameworkPython Via middlewareScrapy deploy tool
⚡ HTTP
Under the hood: Daemon that deploys and runs Scrapy spiders via JSON API. Port 6800. Process-based job queue.
✓ Pros
  • Zero cloud cost, runs on any server
  • ScrapydWeb provides visual dashboard
  • Simple deploy: scrapyd-deploy -p project
✗ Cons
  • Single node by default, no horizontal scaling
  • No built-in monitoring or alerting
  • Job isolation is process-level only
scrapy-redis FrameworkPython N/ADistributed Scrapy
⚡ HTTP
Under the hood: Scrapy extension connecting spiders to a Redis shared URL queue. Enables distributed crawling.
✓ Pros
  • Horizontal scale: add workers without code change
  • Redis deduplicates URLs across all workers
  • One codebase, N machines
✗ Cons
  • Redis is a new SPOF
  • No built-in job scheduling
  • Requires Redis infrastructure
scrapy-cluster FrameworkPython N/AEnterprise Scrapy
⚡ HTTP
Under the hood: Distributed Scrapy cluster using Redis + Kafka + Zookeeper. Enterprise-scale distributed crawling.
✓ Pros
  • True enterprise-scale distributed crawling
  • Kafka for message durability
  • Multi-project support
✗ Cons
  • Complex infra: Redis + Kafka + Zookeeper
  • Overkill for most use cases
  • High ops overhead
scrapy-poet FrameworkPython N/APage Object pattern
⚡ HTTP
Under the hood: Dependency injection framework for Scrapy spiders. Cleaner spider code with page objects.
✓ Pros
  • Cleaner code via page objects pattern
  • Works with zyte-spider and AutoExtract
  • Testable spider logic
✗ Cons
  • Adds abstraction overhead
  • Learning curve for Scrapy veterans
Splash 🌐BrowserDocker Lua scriptingLight protection
🌐 Browser
Under the hood: Lua-scriptable browser for JS rendering, runs in Docker. Integrates with Scrapy via scrapy-splash.
✓ Pros
  • Docker-based, easy to deploy
  • Lua scripting for complex interactions
  • Good for Scrapy integration on JS sites
✗ Cons
  • Outdated, Playwright has superseded it
  • Lua scripting adds complexity
  • Less stealth than Camoufox
selectolax ParserPython N/AFast HTML parser
⚡ HTTP
Under the hood: C-based HTML parser (lexbor engine). 10–100× faster than BeautifulSoup for pure parsing tasks.
✓ Pros
  • Extremely fast, C engine vs Python in BS4
  • CSS selectors with clean Python API
  • Low memory footprint
✗ Cons
  • CSS selectors only, no XPath
  • Less forgiving on malformed HTML than BS4
  • Smaller community/docs
lxml ParserPython N/AXPath + CSS parser
⚡ HTTP
Under the hood: C-based XML/HTML parser. Fastest Python HTML parsing option.
✓ Pros
  • Fastest Python HTML parser by far
  • Full XPath 1.0 support
  • Handles massive documents efficiently
✗ Cons
  • Stricter on malformed HTML than BS4
  • C dependency, occasional install issues
  • Verbose API vs BS4
w3lib ParserPython N/AURL/text utils
⚡ HTTP
Under the hood: Web-related utility functions. URL normalisation, encoding handling. Used internally by Scrapy.
✓ Pros
  • URL cleaning and normalisation
  • Encoding detection and conversion
  • Scrapy internals, very stable
✗ Cons
  • Utility library only, not a scraper
  • Most devs use it via Scrapy, not directly
SwiftShadow ProxyPython N/AProxy pool manager
⚡ HTTP
Under the hood: Free proxy pool manager. Fetches, validates and rotates free proxies automatically.
✓ Pros
  • Free, zero proxy cost
  • Auto-validates and rotates on failure
  • 2 lines of code integration
✗ Cons
  • Free proxies are low quality, high failure rate
  • Not for hard anti-bot targets
  • IP reputation usually poor
requests-ip-rotator ProxyPython N/AAWS API Gateway IPs
⚡ HTTP
Under the hood: Rotates requests through AWS API Gateway endpoints to get rotating IPs.
✓ Pros
  • Free if AWS free tier available
  • AWS IPs have good reputation
  • Works with requests library
✗ Cons
  • AWS API Gateway has rate limits
  • Setup requires AWS account
  • Limited rotation speed
Colly FrameworkGo Go TLSMedium targets15k
⚡ HTTP
Under the hood: Go HTTP scraping framework. Fast, concurrent, clean API.
✓ Pros
  • Very fast, Go concurrency model
  • Low memory vs Python
  • Good for high-throughput HTTP scraping
✗ Cons
  • Go only, no Python
  • Smaller ecosystem than Scrapy
  • No browser support
Katana FrameworkGo Go TLS + ChromiumMedium targets8k
⚡ HTTP
Under the hood: Go-based web crawler by ProjectDiscovery. Designed for security research and recon.
✓ Pros
  • Extremely fast Go crawler
  • Headless mode with Playwright integration
  • Built for large-scale URL discovery
✗ Cons
  • Security/recon focus, not a data scraping framework
  • Go only
  • Less data extraction tooling than Scrapy
playwright-go 🌐BrowserGo CDP (detectable)Medium targets
🌐 Browser
Under the hood: Go bindings for Playwright. Same Playwright API in Go.
✓ Pros
  • Go concurrency for browser scraping
  • Same Playwright API and capabilities
  • Lower memory than Python for concurrent sessions
✗ Cons
  • Less mature than Python Playwright
  • Smaller community
  • No stealth patches yet
Charles Proxy RE ToolAny N/AMobile API intercept
⚡ HTTP
Under the hood: Commercial HTTPS proxy for request inspection and debugging. GUI-based.
✓ Pros
  • GUI-based, easy to use for non-developers
  • SSL proxying with certificate install
  • Session recording and replay
✗ Cons
  • Paid product
  • For debugging only, not automated scraping
  • Less powerful than mitmproxy for scripting
Selenoid HTTPGo (Docker) Browser-as-a-serviceMedium targets2.6k
⚡ HTTP
Under the hood: Docker containers running headless Chrome/Firefox in parallel, Aerokube's Go-based Selenium grid replacement.
✓ Pros
  • Run dozens of browsers in parallel from one host
  • Lower memory than Selenium Grid
  • Built-in video recording per session
  • Drop-in replacement for Selenium Grid
✗ Cons
  • Browsers still detectable as headless without stealth patches
  • Older project, slower release cadence
  • Requires Docker infrastructure
noble-tls HTTPPython Chrome JA3/JA4Cloudflare, DataDome
⚡ HTTP
Under the hood: Python port of uTLS via custom TLS handshake stack, emits browser-matching ClientHello.
✓ Pros
  • Bypasses JA3/JA4 fingerprinting
  • Pure Python, no C compilation
  • Lighter than curl_cffi for simple cases
  • Easy install via pip
✗ Cons
  • Smaller community than curl_cffi
  • Fewer browser impersonation profiles
  • Less battle-tested in production
hrequests HTTPPython Browser-grade TLSDataDome, Cloudflare900
⚡ HTTP
Under the hood: Drop-in requests replacement with TLS impersonation, header order matching, and optional Playwright browser mode.
✓ Pros
  • requests-compatible API with stealth built in
  • Header order mimics real Chrome
  • Optional browser mode for JS rendering
  • Built-in async support
✗ Cons
  • Smaller ecosystem than curl_cffi
  • Fewer impersonate profiles
  • Newer project, some edge cases
crawlee-python 🌐BrowserPython Via curl_cffi backendMost targets6.2k
🌐 Browser
Under the hood: Python port of Apify Crawlee, wraps curl_cffi for HTTP and Playwright for browser modes in a unified framework.
✓ Pros
  • Mix HTTP and browser workers in one crawler
  • Auto-scaling and proxy rotation built in
  • Storage abstraction for results
  • Strong production patterns from Apify
✗ Cons
  • Larger than plain Scrapy
  • Newer than Node.js Crawlee, some features lag
  • Opinionated framework
🌐 Browser
Under the hood: Python port of Apify's Crawlee. Wraps curl_cffi for HTTP and Playwright for browser modes in a unified async framework with built-in retry, dedup, and storage.
✓ Pros
  • Dual HTTP+browser mode in one framework
  • 15K stars, actively maintained by Apify
  • Built-in dataset storage, request queue, proxy rotation
✗ Cons
  • Node.js primary (Python port is newer, less mature)
  • More opinionated than Scrapy, harder to customise
  • Heavier dependency footprint
estela FrameworkPython (K8s) Spider-dependentDistributed Scrapy90
⚡ HTTP
Under the hood: Kubernetes orchestrator for Scrapy, schedules and runs spiders as K8s jobs with auto-scaling.
✓ Pros
  • Open source alternative to Zyte Cloud
  • Elastic scaling on Kubernetes
  • Built-in monitoring and stats UI
  • Multi-tenant by design
✗ Cons
  • Requires Kubernetes infrastructure
  • Heavyweight for small projects
  • Smaller community than Scrapyd
fake-useragent HTTPPython UA strings onlyLightweight only3.8k
⚡ HTTP
Under the hood: Curated database of real-world User-Agent strings, sampled from browser telemetry sources.
✓ Pros
  • Realistic UA strings ready out of the box
  • Filter by browser family or OS
  • Updated database
  • Tiny dependency
✗ Cons
  • UA alone is trivially detectable in 2026
  • Not enough for any modern anti-bot
  • Database can become stale
grequests HTTPPython requests + geventUnprotected APIs4.4k
⚡ HTTP
Under the hood: gevent-monkey-patched requests, fires hundreds of HTTP calls in parallel via greenlets.
✓ Pros
  • Drop-in async for requests users
  • Simpler than asyncio for bulk fetches
  • Battle-tested gevent under the hood
✗ Cons
  • Monkey-patching can conflict with other libs
  • No HTTP/2 support
  • Newer code should use httpx instead
Scrapoxy FrameworkNode.js Proxy managerSelf-hosted rotation2.1k
⚡ HTTP
Under the hood: Self-hosted proxy pool manager, provisions proxies on AWS, Azure, GCP and rotates IPs automatically.
✓ Pros
  • Free open-source alternative to Bright Data's proxy manager
  • Auto-provision and tear down cloud IPs
  • Ban detection and auto-rotation built in
  • Multi-tenant
✗ Cons
  • Cloud provider costs add up at scale
  • Self-hosting infrastructure complexity
  • Cloud IPs flagged faster than residential
Yes Partial No HTTP/Parser/RE Browser Framework AI Managed CAPTCHA Proxy

Browser engines, deep dive

Critical 2026 fact: CDP (Chrome DevTools Protocol) is itself detectable. Runtime.enable timing, execution context leaks, and binding exposure all signal automation. Camoufox uses Mozilla's Juggler protocol below CDP, no CDP leaks. playwright-stealth patches JS at runtime but Function.toString() exposes the patch.
Microsoft 2020
Playwright ★ 68k
Chromium + Firefox + WebKit
The 2026 standard framework. Powers Firecrawl, Crawl4AI, Browserbase. CDP is detectableuse C++ wrappers above Playwright. Auto-wait, network interception, multi-browser.

pip install playwright && playwright install
C++ Firefox · Juggler
Camoufox ★ 100%
Zero CDP exposure · geoip alignment
Mozilla Juggler below CDP levelzero CDP leaks. Near-zero fingerprint surface. 100% pass rate Mar 2026 on Cloudflare, Instagram, Reddit, X. Note: Firefox ~3% market share.

from camoufox.sync_api import Firefox
Stealth Chromium
CloakBrowser
49+ C++ binary patches
Binary patches: Canvas, WebGL, Battery API, AudioContext, CDP input. reCAPTCHA v3 score 0.9. Passes Akamai's 60 extension probes with real extension loading. Best for Akamai-targeted Chromium sites.
Playwright source fork
PatchRight
No JS signatures anywhere
Patches Playwright Python source, not JS injection. Kasada fingerprints playwright-stealth via toString(). PatchRight leaves nothing in the runtime to inspect.

pip install patchright
Google · Node.js
Puppeteer ★ 89k
Chrome DevTools Protocol
Google's original CDP automation. puppeteer-stealth plugin patches common detection points. CDP signature still visible at protocol level. Better for rendering tasks than hard anti-bot targets.
Multi-language · WebDriver
Selenium ★ 29k
Legacy, navigator.webdriver=true
navigator.webdriver=true detectable in 2 JS lines. Use SeleniumBase UC mode to remove. Stock Selenium is dead against Akamai in 2026. Still valid for non-protected targets.
Python · UC Mode
SeleniumBase ★ 10k
Undetected Chrome Mode
UC mode removes navigator.webdriver. Auto-solves many CAPTCHAs. Good for Kasada, medium targets. Not production-safe against Akamai at scale.

from seleniumbase import Driver
Raw CDP · Async Python
nodriver / pydoll
Direct Chrome DevTools Protocol
Direct CDP without WebDriver overhead. Used with Botright for CAPTCHA solving. scrapy-nodriver integrates with Scrapy directly. Lighter than full Playwright for medium targets.
Human behaviour simulation
Botasaurus
Gaussian mouse physics
Physically realistic mouse curves via Gaussian jitter. Combines with Patchright for protocol-level evasion + human behaviour. Effective against DataDome's 35-signal behavioural analysis.

pip install botasaurus
python
from camoufox.sync_api import Firefox

# geoip=True: auto-aligns IP, timezone, locale, WebRTC simultaneously
with Firefox(
    geoip=True        # align all 5 identity vectors to proxy exit country
    humanize=True    # Gaussian mouse jitter
    proxy={"server": "http://proxy.provider.com:8011"
           "username": "user" "password": "pass"},
    screen={"width": 1920 "height": 1080}
) as browser:
    page = browser.new_page()
    # Warm up, never go directly to target URL
    page.goto("https://www.google.com")
    page.wait_for_timeout(2000)
    page.goto("https://cloudflare-protected.com")
    page.wait_for_load_state("networkidle")
    print(page.content()[:500])

The tools above solve the access problem. But once you have the raw HTML or JSON, you still need to extract meaning from it. That is where AI-native scraping changes everything. In 2026 the bottleneck is not access. It is the extraction layer.

05 AI & LLM Scraping

Describe, don't
select

AI-native scraping replaces CSS selectors with natural language. A 2025 NEXT-EVAL benchmark showed LLMs hit F1 > 0.95 on structured extraction when input is properly formatted.

2026 Market Shift
Why AI scraping matters now
Firecrawl's markdown output uses 67% fewer tokens than raw HTML, compounds significantly at thousands of pages for RAG pipelines. AI web scraping market: $7.5B → $38B by 2034 (CAGR 19.93%). LangChain, LlamaIndex, and CrewAI all have native integrations. Claude and Cursor can scrape the web via MCP tools with zero code.
Firecrawl ★ 111k
Managed · Self-hostable · FIRE-1 · MCP
Send URL → clean Markdown/JSON. No selectors. MCP serverClaude scrapes via natural language. FIRE-1 agent autonomously navigates. /interact endpoint clicks, fills forms, extracts behind dynamic content. SAP, Zapier, Deloitte.

app.scrape(url) | app.crawl(site) | app.search("query")
✓ LangChain + LlamaIndex native · 500 free/mo
Crawl4AI ★ 60k
Open-source · Local LLM · Full control · MIT
"Scrapy for the LLM era." Runs on your infrastructuredata never leaves your servers. Adaptive crawling learns selectors over time. BM25 content filter. Plug in Ollama for local models or OpenAI/Deepseek.

result = await crawler.arun(url)
✓ Full data sovereignty, free, MIT license
ScrapeGraphAI ★ 18k
NL prompts · Graph pipeline · Self-healing
Describe what you want, LLM builds and executes a graph-based extraction pipeline. Self-healing: site structure changes, re-describe and it adapts. No selectors ever written. Supports OpenAI, Claude, local.

SmartScraperGraph(prompt="...", source=url)
✓ Best for: schema-free exploration, prototyping
Rust · Chrome TLS · 10 MCP tools · 95.1% accuracy
Rust-native scraper built for AI agent integration. 10 MCP toolsClaude and Cursor can call it directly via natural language. 95.1% success rate on bot-protected sites. Zero Python overhead, runs as subprocess or HTTP service. Chrome-level TLS fingerprinting baked in.

pip install webclaw
✓ Best for: AI agents needing high-performance scraping + MCP integration
Jina Reader API
URL → clean text · Zero code
Simplest LLM scraping tool. r.jina.ai/{url} is the entire API. Returns clean Markdown. Dynamic content handled via built-in rendering. Free tier available, paid ~$0.002–$0.01/page.
✓ Best for: text extraction, no-code integration
Steel
Open-source · Docker · MCP · AI agents
Self-hostable headless browser API for AI agents. MCP serverClaude controls browsers directly. Session persistence + CAPTCHA auto-solve. <1s session start. LangChain/CrewAI integration.
✓ Best for: AI agents needing browser control
Browserbase
Managed cloud · $300M valuation
50M sessions in 2025. Playwright/Puppeteer drop-in, one endpoint swap. Session recordings + CAPTCHA auto-solve. Used by AI agent frameworks as the browser layer. From $50/mo.
✓ Best for: AI agent infrastructure at scale
python
import asyncio
from crawl4ai import AsyncWebCrawler
from crawl4ai.extraction_strategy import LLMExtractionStrategy
from pydantic import BaseModel

# Define exactly what you want, LLM extracts it, no selectors needed
class Product(BaseModel):
    name: str
    price: float
    model_number: str
    brand: str

async def extract(url):
    strategy = LLMExtractionStrategy(
        provider="openai/gpt-4o-mini"
        schema=Product.model_json_schema(),
        extraction_type="schema"
        instruction="Extract all products with prices and model numbers"
    )
    async with AsyncWebCrawler() as crawler:
        result = await crawler.arun(url=url extraction_strategy=strategy)
        import json
        return json.loads(result.extracted_content)
# F1 > 0.95 on well-structured pages, NEXT-EVAL benchmark 2025
MCP Server · 55 production tools · MIT
Crawilfy github.com/razavioo/crawilfy-mcp-server
The full scraping stack as an MCP server — gives Claude Code, Cursor, and Codex 55 production tools for the complete crawling pipeline.

What it ships:
• Stealth via curl_cffi TLS impersonation + rotating proxies
• Auto-discover REST + GraphQL endpoints on any site
• Record a flow once, export it as a runnable Python crawler
• Smart extraction with any OpenAI-compatible LLM (free tiers + local Ollama work)
• MIT licensed

One command: uvx crawilfy-mcp-server

Why this matters: at $0.002–0.01 per request, commercial scraping APIs compound fast on any non-trivial AI agent. Crawilfy brings the full stack in-process: TLS impersonation, proxy rotation, LLM extraction, all from within your IDE. The alternative is paying per-request at scale.
GitHub ↗ PyPI ↗

From extraction to production-grade data

Crawl4AI and Firecrawl get you semantic understanding out of an LLM. But ask an LLM for a price across 10,000 articles and you will get $40, 40 dollars, 40 USD, "forty dollars", and occasionally null. Production pipelines cannot ingest that. The fix is to separate the two concerns LLMs conflate: semantic understanding and structural guarantees.

The pattern · Pydantic + Instructor + LLM
Schema-validated LLM extraction
Define a Pydantic schema for what you want. Pass it to the LLM via Instructor (which patches OpenAI, Anthropic, Mistral clients to return validated schema objects, not free text). Instructor handles retries when the LLM returns malformed output, and rejects responses that fail validation before they enter your pipeline.

# pip install instructor pydantic anthropic
from pydantic import BaseModel, Field
import instructor, anthropic

class JobPosting(BaseModel):
    title: str
    company: str
    salary_min_usd: int | None = Field(description="Floor of salary range in USD")
    salary_max_usd: int | None
    years_experience_min: int
    location: str
    remote: bool

client = instructor.from_anthropic(anthropic.Anthropic())
result = client.messages.create(
    model="claude-sonnet-4",
    response_model=JobPosting,
    messages=[{"role": "user", "content": scraped_html}],
    max_retries=3,
)
# result is a validated JobPosting object, not a string
# If LLM hallucinates "competitive" for salary, Instructor retries
Why this beats raw LLM calls: normalises currencies, units, and phrasings ("just under two percent" → 1.8); rejects hallucinated dates that don't fit the schema; retries automatically on type errors; gives you a real Python object downstream.
When classical NLP still wins
spaCy, NLTK, Stanford NLP at scale
LLMs cost $0.001–0.01 per article on Claude or GPT-5. Classical NLP costs effectively zero after model load. For 10M+ document extraction at scale where the schema is narrow and the domain is stable, spaCy NER + dependency parsing still wins on cost.

Use classical NLP when: scraping millions of consistent documents (e-commerce, classifieds), schema is fixed, domain doesn't shift, latency budget is <5ms per doc.

Use LLM + Instructor when: messy heterogeneous sources (news, newsletters, job boards), context disambiguation matters ("Apple" the company vs the fruit), schema may evolve, semantic equivalences need resolving ("FTE" = "full-time" = "permanent" = "direct hire").

Hybrid in production: classical NLP pre-filters and tags. LLM resolves only the ambiguous cases. This is what Bloomberg, Reuters Refinitiv, and FactSet actually do, not pure LLM pipelines.

Sources and further reading: Federico Trotta, The Web Scraping Club, May 2026; Instructor library.
The production failure mode nobody warns you about: LLMs hallucinate plausibly. If your scraped article doesn't mention a publication date, an LLM will sometimes invent one that fits the article's tone. A Pydantic date | None field with Instructor's retry logic catches this, the LLM has to either find a real date or return None. Without schema validation, fabricated dates pass into your database as facts.
Q2 2026 Landscape · mapped by Massive

The agentic browser stack is 8 layers, not one product

"Browser agent" sounds like a single tool. It's a stack. Most teams building AI agents account for one or two layers; the reliable ones map all eight. When an agent fails a task, the cause is usually not the framework everyone debates, it's one of the other seven layers nobody mapped. The proxy layer sits at the bottom and every layer above it still has to reach the live site.

Layer 1 · Cloud Browser Platforms
Hosted headless browsers at scale
Managed Chrome/Chromium in the cloud, no infra to run. Browserbase, Kernel, Notte, Anchor Browser, Browserless, Hyperbrowser.
Layer 2 · Agent Frameworks & SDKs
Natural-language task → browser actions
Browser Use, Stagehand, Skyvern, AgentQL, Dendrite, Nanobrowser. These translate "log in and download my invoices" into clicks and form fills.
Layer 3 · Browser Automation
The execution primitives
Playwright, Puppeteer, Selenium, Crawlee (by Apify), BrowserMCP. Every layer above eventually calls down to one of these.
Layer 4 · Computer Use Agents
Models that see the screen and act
Anthropic Computer Use, OpenAI Operator, Fellou, Twin, MultiOn. Vision-driven, they screenshot the page and decide the next click rather than reading the DOM.
Layer 5 · Stealth & Anti-Detection
Where most agent tasks silently fail
CloakBrowser, Steel, Lightpanda, Pydoll, Camoufox. A flawless agent framework with a detected browser fingerprint still gets blocked.
Layer 6 · Data Extraction & Enrichment
Page → structured records
Diffbot, ScrapingBee, ScraperAPI, Zyte, ScrapeGraphAI. Turn the rendered page into clean JSON.
Layer 7 · LLM-Optimized Crawling
Crawl output formatted for models
Crawl4AI, Firecrawl, Jina AI, Apify, LLMScraper, Scrapy. Markdown/clean-text output that costs fewer tokens downstream.
Layer 8 · Network & Proxy Layer
The foundation everything depends on
Massive (affiliate), Bright Data, Oxylabs, Smartproxy, NetNut, IPRoyal. A perfect stack with a flagged datacenter IP fails at the first request.
How to use this map when debugging: When an agent fails, don't start with the framework (Layer 2), that's where everyone wastes time. Check Layer 5 (is the browser fingerprint detected?) and Layer 8 (is the IP flagged?) first. The boring layers fail more often than the clever ones. Credit: landscape mapped by Massive, Q2 2026.

When DIY cost exceeds platform cost, these services handle the heavy lifting. Each solves a specific problem, choosing the right one depends on which wall you are facing and at what scale.

06 Managed platforms

When DIY cost
exceeds platform cost

If spending more than 2 engineer-days/month on anti-bot maintenance, a managed platform is cheaper. Crossover typically hits when facing F5 Shape or Kasada at scale.

Bright Data 98.44%
Enterprise · 72M+ IPs · Scrape.do #1 2025
Highest success rate in Scrape.do 2025. 100% on Indeed, Zillow, Capterra. 72M+ residential IPs. GDPR, ISO 27001. Scraping Browser for JS-heavy targets. $1.50/1K requests.
✓ Best for: F5 Shape, hard targets at scale brightdata.com ↗
Zyte 93.14%
#1 Proxyway 2025 · Fastest API · Scrapy
#1 Proxyway 2025, 93.14% success rate. Fastest API response. Smart Proxy auto-selects type. GPTE AI generates parsers from natural language. scrapy-zyte-smartproxy integration.
✓ Best for: Scrapy pipelines, speed zyte.com ↗
Firecrawl ★ 111k
AI scraping · Self-hostable · MCP
URL → Markdown/JSON. No selectors. MCP server, Claude scrapes via natural language. LangChain + LlamaIndex native. Used by SAP, Zapier, Deloitte. 500 free/mo.
✓ Best for: RAG pipelines, AI agents firecrawl.dev ↗
Crawl4AI ★ 60k
Open-source · Local LLM · Free
89.7% OOTB success rate. Runs on your infrastructure. Local LLM support (Ollama). MIT license. Adaptive crawling. Full data sovereignty, data never leaves your servers.
✓ Best for: privacy, open-source, cost $0 crawl4ai.com ↗
✓ Best for: ready-made scrapers, LangChain
Oxylabs
Enterprise · 100M+ IPs · OxyCopilot AI
100M+ IPs, 195 countries. OxyCopilot AI generates parser code from natural language. Owns ScrapingBee (acquired 2025). ISO 27001 + GDPR. From $49/mo.
ScrapingBee
Headless · Managed rendering
Handles JS rendering, CAPTCHAs and proxies. Simple REST API, pass a URL, get back HTML or screenshots. Good for teams that want managed scraping without infrastructure. Free tier available.
scrapingbee.com ↗
Scrapfly
Anti-bot · AI extraction · Monitoring
Premium scraping API with built-in anti-bot bypass, JS rendering, and AI-powered data extraction. Strong on hard targets. Includes scraping monitoring and scheduling out of the box.
scrapfly.io ↗
Diffbot
AI extraction · Knowledge graph
Uses computer vision and AI to automatically extract structured data from any webpage, no CSS selectors, no XPath. Builds a knowledge graph from scraped content. Best for unstructured web data that needs AI parsing.
diffbot.com ↗
WebScraper.io
No-code · Chrome extension
Point-and-click scraping via a Chrome extension, select elements visually, define pagination, export to CSV. No coding required. Cloud version runs scrapers on schedule. Best for non-technical users.
webscraper.io ↗
Browse.ai
No-code · Monitor · Robots
Train a robot to scrape any website in 2 minutes by clicking on the data you want. Monitors for changes, sends alerts. Handles login flows, pagination, and dynamic sites. No code needed at all.
browse.ai ↗
Browser Use
AI agent · LLM-controlled browser
Open-source library that lets LLMs control a real browser. The AI agent navigates, clicks, fills forms and extracts data from instructions in natural language. 81% success rate on anti-bot benchmarks. GitHub ↗
browser-use.com ↗
Stagehand v3 · OCT 2025
AI Browser SDK · Browserbase · Open source
Browserbase's AI browser automation framework. Four primitives: act(), extract(), observe(), agent(). Write browser flows in plain English ("click submit button") that survive page redesigns via runtime LLM resolution. Built on CDP, supports OpenAI/Anthropic/Gemini. 65% Mind2Web benchmark. Self-healing + auto-caching. TypeScript and Python.
browserbase.com/stagehand ↗
Kadoa
AI · Zero-config · Auto-adapt
AI-powered scraping that requires zero configuration, no selectors, no rules. Understands page structure automatically and adapts when sites change. Ideal for scraping at scale without maintaining spider code.
kadoa.com ↗
ScrapeGraphAI
LLM · Graph pipeline · Open source
Builds a graph-based extraction pipeline from a natural language prompt. Describe what data you want, it generates the scraping logic. Open source and self-hostable. Good for rapid prototyping of complex extractions.
GitHub ↗
TinyFish
AI · Structured extraction · Fast
AI-native scraping API focused on speed and structured data output. Pass a URL and a schema, get back clean typed JSON. Handles JS rendering and basic anti-bot. Good fit for feeding structured data into AI pipelines.
tinyfish.io ↗
Nimble
AI · Structured · E-commerce
AI-powered web data platform with pre-built pipelines for e-commerce, SERP, and social. Returns structured data with no parsing needed. Built-in proxy network. Strong for retail intelligence and price monitoring.
nimbleway.com ↗
NetNut
ISP · Residential · Scraping API
ISP-level residential proxy network with a built-in scraping API. Direct carrier connections for lower detection risk. Strong for e-commerce and SERP scraping where IP freshness and session stability matter.
netnut.io ↗
Infatica
Scraper API · SERP · P2B sourcing
Singapore-based provider with both a P2B residential proxy network and a managed Scraper API (POST URL → HTML/JSON, auto-retry, optional render mode for JS-heavy pages, dedicated SERP endpoint with Google AI Overview support). The differentiator vs Zyte/Bright Data/ScraperAPI: explicit peer-to-business IP sourcing, mandatory KYC on buyers, ISO 27001/27701/22301/20000-1 certified. Smaller pool than the giants but priced below them, with a 5,000-request trial. Worth a look when ethics and certification matter as much as raw scale.
infatica.io ↗
Scraping Robot BY RAYOBYTE
Scraping API · 5,000 free/month · JSON output
Plug-and-play scraping API from Rayobyte. Returns clean JSON, handles cookies + headers + browser attributes automatically. 5,000 free scrapes/month on signup, paid tiers from $5/GB. Built on Rayobyte's proxy network and rayobrowse stealth browser. Lower entry barrier than Bright Data or Zyte for teams wanting "scraping as a service" without infrastructure.
scrapingrobot.com ↗
at">✓ Best for: enterprise scale, AI-generated parsers oxylabs.io ↗
5b Adjacent category

Computer Use Agents when scraping isn't enough

A new category emerged in 2025: AI agents that don't just scrape, they log in as the user, navigate any UI (web apps, legacy portals, desktop software), handle MFA and CAPTCHAs, and return structured JSON. Different from scrapers because the user grants permission, "Plaid for any website." If your problem is utility bills, payroll exports, e-commerce backends, or any portal without a public API, this is the category.

Deck FEATURED · $25M RAISED
Computer Use Agents · Credential Vault · SOC 2
Plaid-ifies any website. Provisions isolated desktop VMs, encrypts credentials in Deck Vault, runs AI agents that log in, navigate, and return schema-validated JSON. Founded by the team behind Flinks (Canadian open-banking, acquired for $150M by National Bank). Connects to 100,000+ utility providers across 40+ countries. Handles MFA, CAPTCHA, device fingerprinting, audit-logged sessions. Strong on regulated portals with no public API.
deck.co ↗
Skyvern
Open source · LLM + Computer Vision · 85.8% WebVoyager
YC-backed open-source agent that uses LLMs and computer vision (no XPath or CSS selectors) to operate any browser workflow. State-of-the-art 85.8% on WebVoyager benchmark. Used for invoice retrieval, job applications, government forms, insurance quotes. Both cloud-hosted and self-hostable SDK with Playwright integration.
skyvern.com ↗
Bytebot
SDK · AI browser automation
SDK-first computer use agent platform. Lighter footprint than full VM solutions, integrates into existing apps. Targets developer workflows where you want agentic browser actions without managing browser pools yourself.
bytebot.ai ↗
CloudCruise
Browser automation · Web agents
Developer platform for creating and managing web agents. Focuses on production-grade browser automation infrastructure. Competes with Deck and Browserbase on the infra layer.
cloudcruise.ai ↗
Autotab
Enterprise AI agent · Data + form automation
General-purpose AI agent for enterprise, data collection, form filling, executing actions across business apps. Pitched at operations teams rather than developers.
autotab.ai ↗
Browserless
Managed headless Chrome · CDP-as-a-service
Chrome-as-a-service over WebSocket and REST. Foundation layer that other agent platforms build on. Strong for teams that want managed browser pools without the agent reasoning layer on top.
browserless.io ↗
When to pick this category over scraping: if the data lives behind a login the user owns (their utility bill, their bank statement, their payroll), Computer Use Agents are the right answer, the user permission model gives you a clean legal posture and access to data scraping legally cannot reach. If the data is public-facing (e-commerce listings, SERPs, social), traditional scraping is faster and cheaper.

Platforms sort out the browser and the fingerprint. But every request still needs an IP address, and the type of IP matters as much as any other signal in your stack.

07 Proxy strategy

IP type matters
more than provider

Rotating proxies is table stakes. The real variable is IP type, datacenter IPs score near-zero on DataDome and PerimeterX regardless of fingerprint quality.

Datacenter
Trust: Very Low
AWS/GCP/Azure ranges. Instantly flagged by DataDome and PerimeterX. Cheapest (~$0.01/GB). Use only on non-protected public data. Never for Akamai or PerimeterX targets.
Residential
Trust: High
Real home ISP addresses. Passes most trust checks. Confirmed: curl_cffi + residential bypasses DataDome on Grainger.com. Rotate per session, not per request, mid-session rotation = Akamai block.
Mobile / 4G
Trust: Highest
T-Mobile, Vodafone, O2 carrier IPs. Highest trust score on DataDome and PerimeterX. Shared tower IPs, hard to flag. Mobile IPs get DataDome 200 OK where residential fails. ~$10–15/GB.
ISP / Static
Trust: High
Static residential range. Akamai multi-request scoring rewards consistent IPs, trust accumulates from same ISP IP. Best for long sessions on Akamai sites. Never rotate mid-session.
NetNut
ISP Direct
ISP-based infrastructure with direct carrier connections. Lower detection risk than pooled residential. Fast and stable, good for e-commerce targets that check IP freshness and session age.
IPRoyal
Residential
Ethically sourced residential + datacenter. Pay-as-you-go pricing, no long-term commitment. Good entry point before scaling to enterprise contracts with Oxylabs or Bright Data.
Massive I use this Ethical · Founded 2018
Residential · ISP · Web Access API · Web Render API · MCP Server
Try Massive with my referral ↗ (affiliate)
"I've tested a lot of proxy providers across my 7 years in scraping. Massive stands out for two reasons: the ethics are real (not marketing), and the performance numbers hold up under actual load. 99.87% US success rate and 0.52s response time aren't made up, my production runs match that. If you care about running a clean, compliant operation, this is where I'd start." Asad Ikram, Data Engineer
Residential Proxies
1.6M+ IPs, 195+ countries. 99.87% US success rate. 0.52s response time. GDPR + CCPA compliant, AppEsteem certified. From $4.9/GB.
ISP Proxies
Static residential IPs for sticky, session-bound workflows. 100% success rate, 0.09s response (US). From $1.8/IP. Best for continuous monitoring.
Web Render API
Full JavaScript rendering with anti-bot bypass at scale. From $8/mo. Handles Cloudflare-protected pages without you managing browsers.
MCP Server ✦ new
Official MCP server. Use Massive directly from Claude, Cursor, or any MCP client. Geo-targeted search, bulk extraction, SERP analysis without leaving your AI workflow.
99.87%
US success rate
0.52s
response time
195+
countries
99.9%
uptime
100%
ethically sourced
<20%
fraud score (US)
Verified target success rates
Instagram 96% Amazon 94% Google 88% ISP 100% Trusted by Snowflake · Shopee · Tavily
Startups get 1TB free for 3 months, no equity required. 24/7 live support. GDPR + CCPA compliant. AppEsteem certified.
Join with my referral ↗ (affiliate)
Rayobyte
Ethical · Multi-type
"America's #1 proxy provider" (formerly Blazing SEO, est. 2014). 40M+ residential IPs across 100+ countries, plus ISP, datacenter, and mobile. Non-expiring bandwidth sets them apart, $3.50/GB residential dropping to $0.50/GB at 5TB+. Ethically sourced via Cash Raven consent-based proxyware. Ships rayobrowse stealth browser too. Hands-on technical CEO, partners with EWDCI for ethics standards.
Scrapoxy
Open Source Manager
Self-hosted proxy manager that pools and rotates proxies across AWS, Azure, GCP. Routes requests through different IPs automatically. Free alternative to commercial proxy managers. github.com/fabienvauchelles/scrapoxy
Byteful
Residential · ISP
Residential and ISP proxies pitched at scraping engineers who understand the full detection stack. Honest positioning: "proxies solve IP reputation, but TLS fingerprint, header order, browser behaviour, and request cadence all have to line up independently." Good entry point for teams that already have their TLS and browser layers handled.
Infatica
Residential · Mobile · P2B network
Singapore-based provider that runs an explicit peer-to-business (P2B) sourcing model: they pay app developers to embed their SDK on idle user devices instead of buying SDK installs through opaque intermediary chains. Smaller pool than the giants (~15M IPs vs Bright Data's ~150M, Oxylabs' ~175M) but with city, ZIP, and ASN filtering you can combine, and they claim to not resell the pool to other providers. Distinctive for the market: mandatory KYC on buyers, which is unusual and reduces abuse on the network. Pricing sits below the premium tier (subscriptions from $0.30/GB, pay-as-you-go from $8/GB). Worth a look when you want ethical sourcing and stricter buyer vetting without paying Bright Data prices, accepting that filter coverage by country is thinner than the larger networks.
WebRTC coherence rule: Proxy IP country, WebRTC ICE candidate, DNS resolver, timezone, and Accept-Language must all agree. US residential proxy + Pakistani DNS = flagged by every major anti-bot. Use geoip=True in Camoufox to align all five vectors automatically.
Crawlera/Zyte proxy bug: Port 8011 speaks plain HTTP. Both http:// and https:// keys must use http:// scheme. Using https:// causes BoringSSL WRONG_VERSION_NUMBER (TLS-over-TLS failure). Fix: "https": "http://key:@proxy.crawlera.com:8011/"
python
from curl_cffi import requests
import time random

session = requests.Session(impersonate="chrome124")

# Crawlera/Zyte: BOTH keys use http://, never https://
PROXIES = {
    "http":  "http://apikey:@proxy.crawlera.com:8011"
    "https": "http://apikey:@proxy.crawlera.com:8011"  # http:// not https://
}

def fetch(url retries=3):
    for i in range(retries):
        try:
            r = session.get(url proxies=PROXIES
                             timeout=30 verify=False)  # verify=False: proxy cert
            if r.status_code == 200: return r
            if r.status_code in (403429):
                time.sleep(2**i + random.uniform(01))
        except Exception as e:
            print(f"Error: {e}")
    return None

You now have the full picture: detection layers, six anti-bots, sixty libraries, managed platforms, proxy types. This section collapses all of it into a single decision tree you can follow for any target site.

08 Decision playbook

Walk this in order.
Stop at first win.

Each step adds complexity, cost, and maintenance. Most production scraping is solved at steps 1–3. Never start at step 5.

01
Lowest friction · Asad's priority #1
Find the mobile API
Mobile apps hit same backend with far weaker bot protection. HTTPToolkit intercepts all HTTPS from Android emulator. Frida hooks into SSL_read/SSL_write directly. If you find the API endpoint, every HTML anti-bot becomes irrelevant.
HTTPToolkit
Frida
mitmproxy
Burpsuite
02
XHR reverse engineering
Find the GraphQL or REST endpoint
Chrome DevTools → Network → Fetch/XHR. Many SPAs load from one undocumented JSON endpoint. Confirmed in production, a direct GraphQL endpoint bypassed all Akamai HTML protection.
Chrome DevTools
Burpsuite
webclaw CLI
03
JSON in HTML · No requests needed
Look for embedded state
Next.js embeds full state in __NEXT_DATA__. React SPAs often have >50KB script containing all data. Confirmed: Grainger.com (DataDome-protected), 110KB JS state blob bypasses DataDome entirely because it's in initial HTML.
chompjs
Parsel
BeautifulSoup4
04
HTTP scraping · No browser
curl_cffi + Scrapy
Identify anti-bot with Wappalyzer. curl_cffi with JA4 impersonation resolves most Akamai and DataDome at HTTP layer. Add residential proxy. If __NEXT_DATA__ appears in response, extract it with chompjs.
curl_cffi
Scrapy
Scrapling
05
Browser automation · C++ level only
Camoufox or CloakBrowser
JS injection patches leave signatures. Camoufox: 100% pass rate Mar 2026. CloakBrowser: 49 C++ patches, reCAPTCHA v3 score 0.9, Akamai extension probes pass. PatchRight for Kasada specifically, no JS signatures.
Camoufox ★
CloakBrowser
PatchRight
06
Last resort · F5 Shape only viable path
Managed platform API
F5 Shape's custom VM makes DIY impractical. Token expiry in minutes, payload changes every rotation. At scale: engineer maintenance cost > platform cost. One API flag handles everything. Cost-justify: >2 days/month maintenance → managed API wins.
Bright Data
Zyte
Firecrawl

Quick reference cheat sheet

Anti-botPrimary vectorSteps 1–2 viable?Best toolKey note
AkamaiJA4+ + sensor.js + extension probesOftencurl_cffi + CloakBrowserFind mobile/GraphQL first
CloudflareJA4 Rust edge + TurnstileSometimesCamoufoxOrigin IP via SecurityTrails
DataDome85K ML + WASM boring_challengeYescurl_cffi + mobile IPCheck __NEXT_DATA__ first
PerimeterX5-vector scoreSometimesCamoufox + residentialFresh session per domain
KasadaPolymorphic JS PoWRarelyPatchRight + residentialNever playwright-stealth
F5 ShapeCustom VM + minute expiryNoManaged APIDIY not practical
From the community

What practitioners are
actually shipping in 2026

Fresh insights from engineers actively solving these problems in production. Shared publicly on LinkedIn.

Drag to explore
+
2026 landscape / AI browser stack
The AI Browser Stack: 3 New Layers Nobody Talks About Yet
The AI browser race has the headlines (Atlas, Comet, Dia, new contender every month). But the winner gets decided by what sits underneath. A fresh map of the stack the AI browsers actually run on shows three categories that did not exist a year ago: AI-native browsers, anti-detect platforms, and publisher licensing/tolls.
💡 Publisher licensing is the economic answer to "AI crawlers are scrapers too"
Three additions worth tracking, beyond the agentic browser map already in this guide. (1) AI-native browsers as a top layer: ChatGPT Atlas, Perplexity Comet, The Browser Company's Dia. Not wrappers, full browsers built around an LLM as the primary user interface. They drive the lower layers as agents on behalf of real users, which is part of why Microsoft Edge and V8 quietly stopped enforcing automation-transparency flags (see the "Vendors That Wrote the Detection Rules" card). (2) Anti-detect & fingerprinting platforms as a distinct category: Multilogin, AdsPower, Kameleo. These are not scraping libraries, they are productised browser-profile managers (each profile = a coherent fingerprint with its own canvas/WebGL/timezone/IP), originally for multi-account ecommerce and affiliate work but increasingly used by serious scrapers. Worth knowing about because the techniques inside them are the same fingerprint-coherence rules this guide describes, just packaged with a UI. (3) Publisher licensing & tolls, the genuinely new layer: TollBit, Cloudflare Pay-Per-Crawl, ProRata.ai. The premise: instead of fighting AI crawlers with detection, charge them per access. Publishers expose a paid API for LLMs and agents, with rate-limited free tiers and metered paid ones. This is the economic acknowledgment that AI crawlers are scrapers and that some categories of access are worth paying for. If you build agentic browser systems, this is the layer that may eventually replace bot-detection-as-defense for content-heavy sites. The detection layer is designed to tell bots from people, but the AI browsers on top and the residential networks on the bottom both look the part, so this line is blurring fast. Credit: landscape framing by Massive (Q4 2026 update).
+
2026 reality / Stack composition
Defense in Depth Is Table Stakes Now (26-Site Scan)
A scan of 26 e-commerce and ticketing sites found the same pattern everywhere: the defense is no longer a vendor, it is a stack. Home Depot's sign-in loads Akamai Bot Manager, PerimeterX/HUMAN, Forter, AND reCAPTCHA Enterprise simultaneously. Beating one is tractable. Beating the composition is not.
💡 If you are still planning around a single vendor, you are two layers behind
Five patterns kept appearing across all 26 sites. (1) Stack not vendor: multi-vendor compositions are now the norm, not the exception. (2) Brand names lie: Ticketmaster calls their system "EPS", but open the bundle and you find iamNotaRobot.js, abuse-component.js, aps.js — it is PerimeterX rebranded and served from their own domain. Trust the code, not the label. (3) First-party cloaking: Home Depot serves PX-shaped scripts under random first-party filenames. You cannot identify defenders by checking hostnames anymore, you have to watch how the script behaves at runtime. (4) Lazy-loaded defenses: Ticketmaster ships a reCAPTCHA site key in the homepage JSON but the SDK only loads on login or checkout. Probing only the homepage misses everything. Multi-hop traversal (homepage → login → cart) is the minimum recon bar now. (5) The fingerprint dictates the budget: PerimeterX + behavioral biometrics + reCAPTCHA Enterprise on one page tells you exactly what tier of browser, what kind of proxy, and how slow your automation has to be. Recon is upstream of every other decision. The takeaway: stop asking "which vendor does this site use" and start asking "which stack does this site compose, and where on each layer do I look for cracks."
+
2026 shift / Browser vendors
The Vendors That Wrote the Detection Rules Are Quietly Breaking Them
Microsoft Edge now returns navigator.webdriver = false when an AI agent drives Playwright. Google patched out CDP detection in V8. Neither change was announced. The signals every anti-bot tool relied on to flag automation just became officially unreliable, because AI agents browsing on behalf of real users broke the human-vs-automation binary.
💡 Detection has to move up the stack to behaviour, intent, and network identity
For years the W3C spec required automated browsers to flag themselves via navigator.webdriver = true. That was the easiest detection signal in the industry, and most public anti-bot stacks were built around it (along with CDP-detection tricks for Chrome's DevTools Protocol). Two undocumented changes in 2026 have just made those signals soft: (1) Microsoft Edge returns navigator.webdriver = false when Playwright is driven by an AI agent on behalf of a user; (2) Google patched out the most common CDP-detection technique in V8. No release notes, no announcements. The reason is rational from the browser vendors' side: agentic browsing is now a legitimate use case (Anthropic Computer Use, OpenAI Operator, Browser Use, etc.) and the old binary doesn't apply. The implication for the guide and for production scrapers: any detection or bypass strategy that pivots on these flags needs to assume they are no longer reliable as either signal or counter-signal. Detection has to move up the stack, to behavioural ML, intent patterns, and network-identity layers (TLS JA4, IP reputation, WebRTC, DNS coherence), all of which are far harder to remove from the inside. DataDome's threat-research team published a longer breakdown if you want the technical specifics.
+
Detection vector / Hardware side-channel
"Frost": Tracking Users via SSD Timing, Zero Permissions Required
A new side-channel technique called Frost measures microscopic latencies in the SSD subsystem to fingerprint users and infer activity in other tabs. It requires no permissions, no APIs that prompt the user, and ad-blockers + incognito cannot mitigate it. Standard JavaScript on any page can read these timing variations.
💡 The fingerprinting frontier is now below the JS sandbox layer
Every active tab and every site generates a unique load pattern on the local disk subsystem. By timing common disk-touching operations through standard browser APIs, a script can probabilistically infer what other tabs the user has open and what they are doing in them, without ever requesting filesystem access. Not seen in the wild yet, but the technique class is what matters here: it joins WASM SIMD CPU probes and hyphenation-dictionary checks in a growing family of hardware-level fingerprinting that the browser sandbox does not stop. There is no direct fix until browser vendors add fuzzing or rounding to disk-operation timing, which has a real performance cost they have to weigh. For scraping: any stealth strategy that depends on JS-level patches stops working against this class of probe by design, because the signal is below the JS layer. The medium-term answer is the same one that defeats WASM SIMD probes: real hardware via real devices, not patched browsers in datacenters.
+
Detection vector / Timing attack
Incognito Detection by Timing a Single Byte Write
detectIncognito v1.7 (Nov 2026) integrates a side-channel that detects Chromium incognito mode by writing one byte to navigator.storage and timing the flush. Incognito routes storage to RAM, normal mode hits disk. RAM is faster. That is the entire vulnerability.
💡 <0.1ms flush time = RAM = incognito, no API prompts needed
The technique writes one byte three times to navigator.storage and measures the flush time. Under 0.1ms indicates RAM (incognito), above indicates disk (normal mode). No permission prompts, no API quirks the user can disable, runs in standard JavaScript on any page. Known caveats: RAM disks (used by some privacy-conscious users) trigger false positives unless the threshold is tuned (~0.01ms separates RAM-disk from incognito on test hardware); slow HDDs do not produce false positives because the technique detects suspiciously fast writes, not slow ones. For anti-bot: detecting incognito is a useful behavioural signal (legitimate buyers rarely shop in incognito; scrapers and abuse traffic over-index on it). For scraping: if your stealth stack uses incognito or per-session ephemeral storage to keep contexts clean, you are leaking a signal that is now trivially detectable. The fix is the same as for the broader timing-attack class: use persistent profile directories that hit real disk, accept the cookie/storage management overhead.
+
Build pattern / Self-hosted infra
Browser-as-a-Service: Separate the Control Library from the Binary
John Watson Rooney built a self-hosted stealth-Chrome scraping service and documented every gotcha. The key mental model: Playwright, Puppeteer, and Selenium are control libraries, not browsers. They speak CDP to whatever binary you point them at. Separate the two: run a persistent patched browser on a dedicated machine, connect to it over WebSocket from many scripts.
💡 playwright.connect("ws://...") = one browser service, many clients
The architecture: instead of playwright.launch() spinning up a local browser per script, run a persistent Playwright server on a dedicated box exposing a WebSocket endpoint, and have every scraping script connect("ws://host:3000") as a client. The page can't tell the difference, the API is identical. Five hard-won lessons from the build: (1) Binary choice matters as much as library choice. JS overrides of navigator.webdriver are themselves detectable (wrong property descriptor, wrong prototype chain); source-patched binaries like CloakBrowser remove the signal instead of masking it. (2) Headed via Xvfb beats headless, the virtual framebuffer means nothing looks headless because it isn't. (3) The two-slot trap: Playwright keeps TWO Chromium directories, a full build and a stripped chrome-headless-shell. Replace only the full slot with your patched binary and Playwright silently launches the untouched headless shell instead, you get 403s and the wrong version string with nothing in the logs explaining why. You must replace both slots and rename the headless one to chrome-headless-shell. (4) supervisord inside Docker manages the multi-process reality (Xvfb priority 10, Playwright server priority 20 with startsecs delay). (5) Concurrency = contexts, not instances. One browser, a pool of isolated contexts (separate cookies/storage), workers pull from an async queue, a 403 requeues with backoff and the worker grabs the next job. Proxy creds go per-context so a bad IP just retries with a fresh one. 16 concurrent contexts ran fine on a Ryzen 4650G mini-desktop. Full writeup · github.com/jhnwr/browser-service · YouTube
+
Learning / Mobile API reversing
The Mobile-API Reversing Toolchain: Frida + JADX + Ghidra
Your guide's #1 rule is "find the mobile API first", apps often hit the same backend with zero anti-bot. But intercepting a modern app means defeating its own protections (cert pinning, signed headers). The toolchain: Frida to hook and modify native Java/C functions at runtime, JADX to decompile the APK back to Java, Ghidra to decompile the native C, on a rooted Android emulator.
💡 MobileHackingLab ships a free Frida course with certificate
This is the practical skill that makes "scrape the mobile API" actually work in 2026, when apps defend their endpoints. The workflow: (1) JADX decompiles the APK to readable Java so you can find where the signed header or auth token is generated. (2) If that logic is in a native .so library (common for the sensitive bits), Ghidra decompiles the C/C++ to understand the algorithm. (3) Frida hooks those functions at runtime via injected JavaScript, so you can log the inputs/outputs, bypass certificate pinning, or call the signing function directly to mint valid headers, no need to fully reverse the algorithm if you can just invoke it. (4) Run all of this on a rooted Android emulator from Android Studio for a controlled, disposable lab. Pair with HTTPToolkit or mitmproxy to capture the now-decrypted traffic and recover the API contract. MobileHackingLab offers a free Android Frida course with a certificate and CTF-style challenges, the fastest way in if the toolchain feels intimidating. The payoff: once you can mint the app's signed headers, you call its clean JSON API directly and skip every browser-layer anti-bot entirely. MobileHackingLab free Frida course
+
Tool / Proxy ops
Stop Round-Robining Dead Proxies: Bayesian Selection
Round-robin proxy rotation has a dumb flaw: it keeps sending requests through proxies that are already dead or banned. ProxyOps uses Thompson Sampling to learn which proxies are working right now and route around the rest. Real data over 549,114 requests in 7 days: 76% success with Bayesian selection vs 36% with round-robin. Same proxies, same targets, more than double the success rate.
💡 Treat proxy selection as a multi-armed bandit, not a queue
The core insight: proxy health is non-stationary, a proxy that worked a minute ago may be banned now, and a dead one may recover. Round-robin ignores this entirely and gives every proxy equal traffic regardless of recent performance. Thompson Sampling (a Bayesian multi-armed-bandit method) models each proxy's success probability as a distribution, samples from those distributions to pick the next proxy, and updates beliefs after every request. Good proxies get more traffic, failing ones get probed occasionally to check for recovery but mostly avoided. The benchmark is striking: 76% vs 36% success on identical proxies and targets is not a marginal optimisation, it's the difference between a viable scrape and a failing one. ProxyOps ships this as a full open-source tool, multi-provider inventory, pluggable rotation strategies, per-bot proxy groups, comparison dashboards, on FastAPI + Vue + PostgreSQL, Dockerized (docker compose up). MIT licensed. github.com/Paulo-H/proxyops
+
Tool / Concurrency
Validating Millions of Public Proxies: Why Python Wasn't Enough
Public proxy lists are mostly dead, slow, or pre-blocked. Validating them at scale before a scrape becomes its own engineering problem. One builder hit the wall with Python threads checking proxies for Google scraping, then rebuilt the validator in Go. The lesson: Go is exceptional for I/O-heavy concurrent workloads where Python's threading model bottlenecks.
💡 Validate the pool before the scrape, in Go, not inline in Python
The bottleneck most people don't anticipate: if you rotate through huge lists of free/public proxies to avoid rate limits, you spend more time discovering which proxies are alive than actually scraping. Doing this inline with Python threads doesn't scale, the GIL and thread overhead cap you well below the concurrency a proxy-check workload needs (it's almost pure network I/O with tiny CPU cost, the ideal case for lightweight concurrency). Go's goroutines and channels handle tens of thousands of concurrent connection checks on modest hardware, with far better memory efficiency than Python threads or even asyncio for this specific pattern. The architecture takeaway generalises: separate proxy validation into its own high-throughput service (in Go or Rust), maintain a continuously-refreshed pool of known-good proxies, and have your scraper pull only from validated proxies rather than checking inline. Useful well beyond scraping, the same pattern applies to OSINT, network reconnaissance, and distributed systems. github.com/harshit-singh-ai/proxy-validator
+
Case study / CDN routing gap
Bypassing a Queue-It Virtual Waiting Room via a CDN Gap
FlySafair put its whole site behind a Queue-It virtual waiting room (a Cloudflare Worker checking for a queue token) during a flash sale. But two paths, /check-in and /manage, were served from a separate AWS CloudFront origin that was never routed through the Worker. And that origin served the entire SPA bundle.
💡 If any path serves the SPA bundle, it must enforce the same queue
The bypass chain is a masterclass in CDN-gap exploitation. (1) Recon: probe the public sitemap, log response headers per path. Most paths returned Cloudflare headers and redirected to the queue. Two paths (/check-in, /manage) returned AWS CloudFront headers, a completely separate origin. (2) That CloudFront origin didn't serve a lightweight stub, it served the full single-page-app bundle, the same JavaScript that powers the booking flow. (3) The bundle still runs Queue-It's client-side connector on load, which calls assets.queue-it.net and redirects if no token. But that check fires AFTER the browser has the full bundle. Block assets.queue-it.net in DevTools and the check never fires. (4) Because it's an SPA, once the bundle is running every navigation is client-side. Two console lines, history.pushState({}, '', '/') then dispatch a popstate event, render the home page with zero new server requests. Queue entirely bypassed. The root cause isn't a Queue-It bug, it's a CDN routing gap: most of the site went through Cloudflare with the Worker active, but two paths on a separate CloudFront origin served the same SPA without enforcement. Full writeup on GitHub
+
Benchmarks / 2026 data
Distributed Browsers: The "Residential Proxy Moment" for Stealth
The Web Scraping Insider benchmarked stealth browser APIs (April 2026): Scrapeless 90.95, Bright Data 89.05, Oxylabs 85.71, then a cliff. The bigger idea from Driver.dev: as anti-bots fingerprint GPU and hardware entropy, cloud stealth browsers may become the new datacenter proxies, detectable by default, pushing the field toward real-device browser networks.
💡 Cloud browsers → real-device browser networks, mirroring DC → residential
Three data points worth internalising from the April 2026 benchmarks. (1) Stealth browser APIs are measurably different: Scrapeless (90.95), Bright Data Scraping Browser (89.05), Oxylabs Headless (85.71) lead, then most providers fall off a cliff for the same reason, automation signals leak, and once that happens proxy rotation doesn't save you. (2) Cloudflare bypass has no single winner: across 8 approaches tested on 20 protected sites, only 3 had broad coverage, smart proxy APIs, TLS impersonation (curl_cffi), and browser APIs. Different domains use different protections, so what works on one target fails on another. (3) The structural prediction: anti-bots increasingly fingerprint the whole environment (browser, GPU, hardware entropy, OS quirks), which means a stealth browser running in a datacenter is detectable simply by being in a datacenter, regardless of how good its fingerprint patches are. The likely evolution mirrors proxies exactly: datacenter proxies gave way to residential proxies, and cloud stealth browsers may give way to distributed browser networks running across real consumer devices. The fingerprint isn't patched, it's genuinely real, because it's a real device.
+
Concept / Shift in thinking
The Web Is Becoming a Real-Time Database for AI Crawlers
Classic scraping: crawl on a schedule, store in a database, query the database. With cheap residential proxies, a new pattern emerged: don't store anything. The target website is your database. Scrape on demand, treat every page load as a query. For AI crawlers especially, why save data when you can fetch it live whenever you want?
💡 Resproxies made scraping cheap enough to skip storage entirely
This is a genuine shift in how scraping infrastructure gets designed. The old model assumed scraping was expensive and risky, so you scraped once, stored aggressively, and served queries from your own database. That meant stale data, storage costs, and sync logic. Residential proxies changed the economics: scraping became cheap and reliable enough that for many use cases you can just hit the live site every time a user (or an AI agent) asks. The website hosts the data, you treat it as a remote database, and the latency tradeoff is acceptable because the customer is willing to wait a few seconds for fresh answers instead of getting instant but stale results. For AI crawlers and agentic workflows this is even more pronounced, there's no point caching a price or a flight time when the agent can re-fetch it at query time. The implication for anti-bot teams: scraping volume is no longer bounded by "how often do they refresh their DB", it's bounded by "how often does a user ask", which can be far higher and far spikier.
+
Landscape / Agentic browsers
"Browser Agent" Is Not One Product — It's 8 Layers
Massive mapped the agentic browser infrastructure landscape for Q2 2026. The insight: most teams building AI agents think about one or two layers. The reliable ones account for all eight. When an agent fails a task, the cause is usually not the framework everyone debates — it's one of the other seven layers nobody mapped.
💡 Every layer above the network still has to reach the live site
The eight layers of the 2026 agentic browser stack: (1) Cloud Browser Platforms — Browserbase, Kernel, Notte, Anchor Browser, Browserless, Hyperbrowser. (2) Agent Frameworks & SDKs — Browser Use, Stagehand, Skyvern, AgentQL, Dendrite, Nanobrowser. (3) Browser Automation — Playwright, Puppeteer, Selenium, Crawlee, BrowserMCP. (4) Computer Use Agents — Anthropic CUA, OpenAI Operator, Fellou, Twin, MultiOn. (5) Stealth & Anti-Detection — CloakBrowser, Steel, Lightpanda, Pydoll, Camoufox. (6) Data Extraction & Enrichment — Diffbot, ScrapingBee, ScraperAPI, Zyte, ScrapeGraphAI. (7) LLM-Optimized Crawling — Crawl4AI, Firecrawl, Jina AI, Apify, LLMScraper, Scrapy. (8) Network & Proxy Layer — Massive, Bright Data, Oxylabs, Smartproxy, NetNut, IPRoyal. The proxy layer sits at the bottom and everything above it depends on it: a perfect agent framework with a flagged datacenter IP still fails. Most agent debugging focuses on layer 2 (the framework) when the actual failure is layer 5 (detection) or layer 8 (the IP). Map all eight before you debug one.
+
Architecture / Resilience
Pub/Sub: Why Sequential Crawlers Don't Scale
A threat-intel crawler hitting 1000+ sources started as one service crawling sequentially. Two failures emerged: latency grew linearly with each new source, and one broken source took down the entire pipeline. The fix wasn't more compute — it was event-driven pub/sub architecture.
💡 If N sequential steps can each kill the rest, that's an architecture problem
The pattern: a publisher pushes one message per source to a broker (SQS, Kafka, RabbitMQ, Google Pub/Sub). Independent worker subscribers pull messages and crawl in parallel, completely isolated from each other. When one source breaks — a timeout, a layout change, a 500 — it fails alone in its own worker. The rest of the pipeline never notices. Three properties fall out of this for free: (1) ingestion latency stays flat regardless of source count, because workers run concurrently not sequentially; (2) failures are isolated by design, with a dead-letter queue capturing the broken messages for retry; (3) the system scales horizontally — add more subscriber workers, get more throughput, no code change. This is the difference between a script that crawls 50 sources and a platform that crawls 50,000. I added a full architecture diagram for this pattern in the Architecture section (tab: Pub/Sub Event-Driven). The takeaway generalises beyond scraping: any pipeline where one slow or broken step blocks all the others is one message broker away from being resilient.
+
Detection / OS fingerprinting
The Detection Vector Nobody Patches: Hyphenation Dictionaries
Chromium on Windows and Linux requires a hyphenation dictionary to be bundled at build time. Most custom Chromium forks ship without one. The result: many stealth browsers literally cannot hyphenate words — a signal anti-bots can probe via hyphens: auto CSS and measure rendered output.
💡 Camoufox, PatchRight, undetected forks — check yours with the PoC
When CSS hyphens: auto is set and text overflows a container, the browser inserts soft hyphens at language-specific break points (so "hyphenation" becomes "hy-phen-ation"). The dictionary that drives this is OS-level on Android and macOS, but Chromium on Windows and Linux must bundle it at build time. Most people forking Chromium don't know this — the build artifact is large and the feature is invisible until you specifically test it. Joe (joe12387) demonstrated this is a detection vector: anti-bot scripts can render a known word in a known-width container with hyphens: auto, screenshot via Canvas, and compare the hyphenation positions against expected values for the claimed OS. A custom Chromium fork that fails to hyphenate at all (or hyphenates wrong) reveals itself instantly. Mitigation: ensure your build includes the hyphenation dictionary for the languages you claim to support, or run real Chromium binaries (not forks) under XVFB instead. Live PoC · github.com/joe12387
+
Workflow / AI-assisted recon
Burp Suite MCP + Claude Code = Anti-Bot Recon in Minutes
PortSwigger shipped an MCP server for Burp Suite. Point it at Claude Code and the hours-long ritual of tracing which cookie unlocks which route, when the sensor payload fires, what gets re-validated on POST — collapses into a single prompt. The bar for what counts as anti-bot recon just moved.
💡 Build a burp-antibot-recon SKILL.md and replay it across targets
The classic anti-bot recon workflow: capture a session through Burp, scroll the HTTP history one request at a time, manually trace cookie flows (_abck, datadome, cf_clearance, reese84), identify sensor.js challenge endpoints, figure out which requests trigger re-validation. For a moderately complex target like nike.com, this takes hours per session. With Burp's MCP server pointed at Claude Code, you capture the same session and prompt: "trace the _abck cookie lifecycle from home page through add-to-cart, identify all sensor payload endpoints, and explain the validation flow." Claude reads Burp's full history directly and produces the analysis in seconds. The pattern scales: build a reusable burp-antibot-recon Skill once, replay it across Akamai/DataDome/Cloudflare targets. If you work in this space and haven't wired it up, this is the unlock. github.com/PortSwigger/mcp-server
+
Trending / Browser stealth
CloakBrowser Just Crossed +9.1K Stars in One Week
The fastest-growing GitHub repo this week is a scraping tool. CloakBrowser, the stealth Chromium with source-level fingerprint patches, hit +9.1K stars (Nov 2026), passing 30/30 anti-bot tests. Confirms what production scrapers already knew: real browsers with patched binaries beat stealth plugins.
💡 Drop-in Playwright replacement, no JS patches to detect
Stealth plugins (puppeteer-extra-stealth, playwright-stealth) overwrite JS properties at runtime — which is itself a detection signal. Anti-bot scripts can see the override happen. CloakBrowser patches Chromium's C++ source directly so the fingerprint is real at the binary level. There's no override to detect. The recent velocity (+9.1K stars in one week) was driven by it passing every public anti-bot test suite including Sannysoft, Antoinevastel, Creepjs, and Bot.sannysoft. Its closest analogue is Camoufox (Firefox-based, same approach with Juggler) but CloakBrowser uses Chromium so it works with existing Playwright pipelines. The tradeoff: maintenance burden. When Chrome ships a new version, CloakBrowser has to patch and rebuild. The team has been keeping up so far. github.com/CloakHQ/CloakBrowser
+
FOSS Defense / Anti-AI
Anubis: The Anime-Mascot Firewall Protecting FOSS
Self-hosted Web AI Firewall (15k+ stars) built by Xe Iaso. Used by Codeberg, FFmpeg, the Linux kernel docs, Sourcehut. Issues a JS proof-of-work challenge with a furry-eared mascot. Codeberg admitted in mid-2025 that AI bots already learned to solve it.
💡 PoW slows scrapers but headless Chromium solves it naturally
Anubis is the new category of anti-scraper protection most guides miss: self-hosted, FOSS-targeted, AI-scraper-focused. Unlike Cloudflare and Akamai (enterprise SaaS), Anubis runs as a reverse proxy on the same server as the protected site. The challenge is pure client-side JavaScript proof-of-work — the browser hashes until it finds a nonce matching a difficulty target. For real users this is invisible (~1-3 seconds on modern hardware, painful on old phones). For scrapers using plain requests or curl_cffi, the challenge is unsolvable without JS execution. The bypass is mundane: any headless browser (Playwright, Camoufox, Patchright) with JS enabled will solve it automatically. Persist the auth cookie (techaro.lol-anubis-auth) and reuse it across requests. The political angle: Anubis exists because AI scrapers (OpenAI, Anthropic, Common Crawl, ByteDance) were DDoSing small FOSS projects by ignoring robots.txt. It's a community response, not a commercial product. github.com/TecharoHQ/anubis
+
TLS / Anti-bot
Cloudflare Turnstile Solved Without a Browser
Solvable with pure HTTP, no browser needed. Reverse-engineer the POST payload: 79 parameters covering Canvas, WebGL, Timing and crypto hashes. Status 200 in 0.27s.
💡 Turnstile PoW is solvable in under 1s via plain HTTP
The Turnstile POST payload contains 79 parameters. Key groups: Fingerprint (Canvas hash via OffscreenCanvas, WebGL renderer, AudioContext output), Browser Environment (navigator properties, screen dimensions, timezone), Interaction sequence (mouse path, click timing), and Crypto (custom SHA-256 + TEA encryption of the challenge nonce). The Sitekey is extracted automatically from the page source. Algorithms used: Custom SHA-256, TEA block cipher. Token format: Encrypted_Data-Timestamp-Version-Checksum. Full flow: extract Sitekey → initiate challenge → construct responses → generate 95-char token. Result: cf_clearance accepted in 0.27s. No browser process needed.
+
TLS / Proxies
Why "Just Get Better Proxies" Stopped Working
The problem is your TLS handshakenot your IP. Cipher suites, HTTPS extensions, GREASE values form a JA4 fingerprint. A clean residential IP still fails if the fingerprint exposes you.
💡 The residential IP passed. The fingerprint gave it away.
TLS detection happens at the ClientHello level, before any HTTP is exchanged. The JA4 fingerprint hashes: cipher suite list (sorted), TLS extensions (sorted, GREASE removed), ALPN protocols. Python's requests library sends a different cipher suite order than Chrome. httpx is different again. Even with a clean residential IP, if your cipher ordering does not match Chrome's, you are identified before the server processes a single header. Fix: use curl_cffi with impersonate="chrome124"it emits Chrome's exact TLS ClientHello. Also watch HTTP/2 SETTINGS frames, they contain window sizes and header table parameters that vary per client.
+
Network Identity
The WebRTC Trap: Your Browser Is Leaking Your Real Location
Proxy says US. WebRTC says elsewhere. It leaks your real IP via STUN and creates geo mismatches. Anti-bots check that IP + WebRTC + timezone + DNS + Accept-Language all agree.
💡 Quick test: browserleaks.com/webrtc, check before blaming your proxy
WebRTC uses the STUN protocol to discover network paths. During ICE candidate gathering, the browser contacts a STUN server and reports: your real public IP, your local LAN IP (e.g. 192.168.x.x), and all network interface addresses. Your proxy only routes HTTP/HTTPS traffic, WebRTC bypasses it entirely. Anti-bots cross-check: proxy exit IP vs WebRTC public IP vs DNS resolver location vs Accept-Language vs timezone. All five must agree. Fix with Camoufox: set geoip=True and it automatically aligns all five vectors. Do not simply disable WebRTC, it removes a feature that 99% of real users have, which itself becomes a bot signal.
+
Benchmarks · 2026
The 30-Point Gap: Browser Scraping Success Rates Are Not Equal
71 protected sites tested: Browser Use Cloud hit 81%Browserbase hit 42%. That gap is no longer marginal, it is the difference between a working pipeline and a broken one.
💡 A 30-point gap in success rate = the difference between a working pipeline and a broken one
The benchmark tested 71 sites protected by Cloudflare, Akamai, PerimeterX, and DataDome. Methodology: each provider was given identical target lists and measured on first-request success (no retries). Browser Use Cloud succeeded on 81%, achieved via custom Chrome patches at the C++ binary level plus coordinated fingerprint management. Browserbase succeeded on 42%, detected primarily via CDP timing signatures and canvas hash consistency. The gap exists because basic scraping (fetch URL, parse HTML) is commoditised. The data worth having in 2026 sits behind login walls, search interfaces, and multi-step authenticated flows requiring actual browser interaction. Cheap providers are adequate for unprotected targets; they fail silently on protected ones.
+
Architecture
Browsers as a Session Layer, Not a Scraping Product
HTTP is fast, browsers are expensive. Right architecture: browser for session warmup and hard challenges onlythen lightweight HTTP workers for bulk collection.
💡 Browser for session warmup → HTTP for bulk collection
The architectural insight: most scraping pipelines use browsers for everything, which is expensive. But you only actually need a browser for two things: (1) session establishmentgenerating valid cookies and session tokens that a protected site will accept, and (2) hard challenge pagesAkamai sensor.js, Cloudflare Turnstile, DataDome WASM challenges. Once you have a valid session cookie, the rest of the data collection can happen via lightweight HTTP requests at 10-100× the speed and 1/100th the memory. Implementation: use camoufox or rayobrowse to generate sessions, then curl_cffi with the extracted cookies for bulk collection. Rotate sessions every 30-50 requests.
+
Python Framework
Scrapling v0.4: The Biggest Python Scraping Update Yet
New async spider: concurrent crawling, mix HTTP and stealth sessions, pause/resume from checkpoint, stream items live. Thread-safe ProxyRotator built in. Handles Turnstile natively.
💡 pip install scrapling --upgrade
The async spider framework uses a Scrapy-like API: define a Spider class, set start_urls, implement parse(). Key differentiators from Scrapy: mixed session types in one spider (HTTP fetchers, headless Camoufox, stealth browser), checkpoint/resumeCtrl+C saves state, restart continues from last position, per-domain throttlingset different rates per target. ProxyRotator: thread-safe, works across all fetcher types, supports custom rotation strategies, per-request override. Parser improvements: blocked_domains list to block tracking/CDN requests in headless mode, automatic proxy-aware retry on network errors, Response.follow() for easy link chaining. Install: pip install scrapling --upgrade.
+
Proxies
SwiftShadow: Free Proxy Rotation Without the Headaches
Grabs free proxies, validates, rotates automatically, filters by country. Built-in caching, auto-switches on failure. ~300 stars, actively maintained.
💡 pip install swiftshadow, from swiftshadow import QuickProxy
SwiftShadow maintains a pool of free proxies sourced from multiple public lists. On initialisation it validates all proxies (checks response time and anonymity level) and caches the working set. When a proxy fails mid-request, it automatically switches to the next validated proxy in the pool, no intervention needed. The QuickProxy(countries=["FR","DE"]) API filters by exit country. The built-in cache means it does not hit proxy list APIs on every request. Usage: from swiftshadow import QuickProxy; proxy = QuickProxy(); session.proxies = {"http": str(proxy), "https": str(proxy)}. Important: free proxies have high failure rates and low anonymity, do not use for Akamai, DataDome, or PerimeterX targets. Best for scraping open/unprotected sites at scale without cost.
+
RAG / LLM Pipelines
Keep Your LLM Context Fresh: Incremental Indexing
Scraped data goes stale fast. CocoIndex builds a continuously updated vector indexonly changed rows re-run. Pgvector, LanceDB, Neo4j targets. #1 GitHub Trending on launch.
💡 github.com/cocoindex-io/cocoindex, incremental RAG for LLM agents
The core problem: you scrape a site, embed it into a vector store, and 48 hours later 30% of the content has changed. Traditional batch re-indexing re-processes everything. CocoIndex solves this with a Rust-based delta engine: it tracks byte-level lineage per document, and when you re-run it only processes changed chunks. Target vector stores: Pgvector (PostgreSQL), LanceDB (local), Neo4j (graph). Python with Rust core means the delta calculation is very fast even on large corpora. The LLM integration: your agent always queries a fresh index, so answers reflect current scraped data. Setup: pip install cocoindexconfigure sources (files, URLs, S3), define your chunker and embedding model, run cocoindex.build()done in under 10 minutes.
+
API-First Scraping
Skip the HTML. Hit the API. 50× Faster.
Open DevTools Network → Fetch/XHR before writing any code. Half the time the page calls a JSON API directly. 50× faster, 100× less memory, zero browsers launched.
💡 Rule: open DevTools Network tab before writing any code
The technique: open Chrome DevTools → Network tab → filter by Fetch/XHR. Reload the page. Look for requests returning JSON. Right-click → Copy → Copy as cURL. Run that cURL command. If you get the same data back, you have found the internal API. What to look for: GraphQL endpoints (POST to /graphql or /api/graphql), REST endpoints (GET to /api/v2/products, etc.), __NEXT_DATA__ (Next.js embeds full page state in a JSON script tag, no request needed, just parse the HTML). Benefits: bypasses most anti-bot because APIs typically have weaker protection than HTML endpoints, returns clean structured data instead of HTML you need to parse, no browser needed, runs at full HTTP speed. When this fails: auth cookies required, the API uses rotating tokens, or the site detects API scraping specifically.
+
Library Analysis
Scrapling Hit 200K Views, Invest in Your Network Layer
Detection vendors update, bypass libraries break, new ones ship. This cycle repeats every few months. What never depreciates: your proxy infrastructure. Invest there first.
💡 Invest more in your network layer, it depreciates slower than your library
The library lifecycle in scraping works like this: a new bypass technique is discovered, someone publishes a library implementing it, the library becomes popular, detection vendors add the library's fingerprints to their models, the library gets blocked, repeat. This cycle runs on a 2-4 month cadence for fast-moving targets. Your proxy setup operates on a different timeline: a well-configured residential proxy pool with good IP diversity and correct session management continues to work across multiple library generations. The specific libraries come and go but the network signals (IP reputation, ASN, session behaviour, timing patterns) remain consistent requirements. Conclusion: spend more engineering time on proxy quality, session management, and IP pool diversity than on tracking the latest bypass library.
+
Learning Path
Scraping Tutorials Teach the Wrong Things First
Most start with BeautifulSoup on static HTML. Real scraping is JS-rendered, sessions, rate limits, dynamic APIs. Better: DevTools → XHR replication → Scrapy → anti-bot.
💡 DevTools → XHR replication → Scrapy → anti-bot, in that order
The typical tutorial sequence: install Beautiful Soup, parse static HTML, extract data. This teaches the wrong mental model. Real production scraping involves: JavaScript renderingmost modern sites build their UI client-side, the HTML you fetch is an empty shell, Sessions and authcookies, CSRF tokens, login flows, Rate limiting and backoffexponential backoff, per-domain limits, Dynamic selectorssites change their HTML structure, you need adaptive extraction. The right learning sequence: DevTools Network tab → understand how data flows between client and server → learn to replicate XHR requests with requests/curl_cffi → Scrapy for structure and scale → fingerprinting and anti-bot bypass last. Understanding what actually happens when a browser loads a page is more valuable than memorising BeautifulSoup APIs.
+
IoT / Edge
A Microcontroller Scraping Live Weather Data via API
An ESP32 calling a scraping API, parsing JSON, displaying on TFT screen. The abstraction is now clean enough for devices with no Python. Scraping as real infrastructure.
💡 Scraping APIs are now clean enough for Arduino, #esp8266 #esp32
An ESP8266 microcontroller running Arduino firmware makes an HTTPS request to a scraping API endpoint. The API (Zyte) handles: TLS negotiation with the target, JavaScript rendering if needed, anti-bot bypass, data extraction. The microcontroller receives clean JSON back and renders it on a TFT display. This demonstrates that scraping has become a proper infrastructure layer, just like how you would call a weather API, you can now call a scraping API from any HTTP-capable device. The broader implication: scraping is no longer just a Python script on a server. It is a data access layer that any application can use. The complexity of browser fingerprinting, proxy rotation, and anti-bot evasion is fully abstracted behind a simple API call.
+
Debugging
Your Scraper Is Blocked Because of Behaviour, Not Code
Identical headers. Machine-speed intervals. No session state. Datacenter IPs. Fix: rotate headers, random.uniform(1.8, 4.3) delays, requests.Session(), residential proxies.
💡 sleep(random.uniform(1.8, 4.3)) beats sleep(2) every time
The signals that get you blocked, in order of detection speed: TLS fingerprint (detected before first HTTP byte), HTTP/2 SETTINGS frames (detected at connection), Request headers (User-Agent, Accept-Language, Sec-CH-UA, checked immediately), Request timing (identical intervals are machine-like), Session patterns (no cookies accumulated, no referrer chain), IP reputation (ASN, datacenter range). Fix each layer: curl_cffi for TLS, full Chrome headers via httpx or curl_cffi, random.uniform(1.8, 4.3) delays, requests.Session() for cookie accumulation, residential/mobile proxies for IP. Check your current fingerprint at tls.browserleaks.com/json.
+
Mental Model
Understanding Beats Tools Every Time
Not curl_cffi, not Playwright, not a $300/mo plan. Understanding how detection works is the real advantage. Tools change. Detection evolves. Understanding transfers.
💡 "Tools change. Detection evolves. Understanding is what transfers."
The mental model shift: most scrapers think in terms of tools ("which library bypasses Cloudflare?"). Experienced scrapers think in terms of signals ("which signals is my scraper leaking that Cloudflare can detect?"). The difference: tool-thinkers update their library when it breaks. Signal-thinkers understand why the library broke and can fix it themselves or identify the correct replacement. Signals Cloudflare checks: JA4 TLS fingerprint, HTTP/2 SETTINGS frames, navigator properties (webdriver, plugins, languages), Canvas hash, WebGL renderer, timing patterns, IP reputation. If you know which signal you are leaking, you can fix it regardless of which library you are using. This understanding also transfers to new anti-bots, the signals are similar across vendors even though the implementations differ.
+
AI Visibility · 2026
Top 10 Scraping APIs per ChatGPT + Perplexity + Gemini + Google
All four AI models queried simultaneously. Consensus: 1. Bright Data · 2. Zyte · 3. ScrapingBee · 4. Firecrawl · 5. Scrape.do. Half of B2B buyers now start research in AI chatbots.
💡 AI search is a real channel, Bright Data #1 across all four models
The research methodology: a scraping API was used to query four AI systems simultaneously from a San Francisco IP address (to simulate a US-based B2B buyer). Prompt: "best web scraping API 2026". Results aggregated by occurrence and ranking position. Full ranking: 1. Bright Data (98.44% success, 72M+ IPs), 2. Zyte (93.14%, #1 Proxyway benchmark), 3. ScrapingBee, 4. Firecrawl (111K GitHub stars, LLM-optimised), 5. Scrape.do, 6. ScraperAPI, 7. Apify, 8. Scrapingdog, 9. Oxylabs, 10. Scrapfly. The AI search SEO implication: if you are building a scraping product, being in AI training data and AI search indexes is now a primary distribution channel. The buyers searching "best scraping API" increasingly ask an AI chatbot, not Google.
+
Browser stack / Serverless
XVFB + Headed Chrome + Nodriver Even on Serverless
The real breakthrough is not header spoofing. It is running a real browser in a real headed environment, even on serverless. Modern anti-bots are trained to detect machines pretending to be browsers, so the answer is to actually be one.
💡 The future belongs to systems that execute like real humans from the ground up
A few years ago, simple HTTP requests were enough. Today Cloudflare, DataDome, Akamai, and HUMAN Security analyse hundreds of browser, network, and behavioural signals simultaneously. The stack you choose now matters more than the proxy you point it at.

Detection risk by stack (lowest is best):

Stack Detection Risk Limitation
requests / httpx Very High No browser rendering
Scrapy Very High No behavioural realism
Headless Browser High Headless traces (WebGL=null, missing extensions)
Stealth Headless Medium Partial spoofing, JS patches detectable
XVFB + Headed Browser Lowest Higher data consumption
The full stack:
✓ XVFB virtual display (real X11 server, not headless flag)
✓ Fully headed Chrome (no --headless anywhere)
✓ Nodriver for CDP without webdriver artefacts (or Camoufox for Firefox)
✓ Authentic TLS / HTTP-2 behaviour (the browser handles this for free)
✓ Humanised interactions (Bezier-curve mouse, variable scroll timing)
✓ Residential proxies, sticky session for trust accumulation
✓ Fingerprint coherence (UA + WebRTC + DNS + timezone all match exit IP)

Why XVFB beats --headless even with stealth patches: headless Chrome reports HeadlessChrome in the user agent (fixable), missing extensions (probe-able), and zero GPU context (the real killer). With XVFB you get a real display, Chrome runs in headed mode, extensions load normally, and the GPU stack is whatever your server provides. JS patches still leave Function.prototype.toString() traces; XVFB does not.

The serverless angle: the conventional wisdom is that serverless cannot run a real browser. The trick is provisioning an X11 socket inside the container (Xvfb :99 &, DISPLAY=:99 chrome ...) so Chrome runs headed on a virtual display. Lambda has hit memory limits historically, but ECS Fargate, Cloud Run, and Modal handle this comfortably with ~1GB memory per browser instance. The result: serverless infrastructure behaving like real users, not automation.

What still beats XVFB: C++ patched browsers like Camoufox (canvas, WebGL, audio at the binary level) and CloakBrowser (real extension probe profiles) close the remaining 10%. But for the 80-90% of targets where XVFB + Nodriver gets you in, the cost difference is significant. Camoufox: 200MB+ per instance. XVFB headed Chrome: same memory but works on any Chromium binary.

Modern anti-bot systems are trained to detect machines pretending to be browsers. The path forward is not better lies, it is fewer lies.
+
Detection / WASM
The Detection Layer Your Stealth Browser Cannot Patch
WebAssembly SIMD probes the actual CPU. WebAssembly shared memory gives anti-bots a 17× higher-resolution timer than performance.now(). Both run below the JS hooks Camoufox, CloakBrowser, and PatchRight patch.
💡 The arms race of better JS patches has a ceiling. WASM fingerprinting is past it.
The DataDome engineering team published in May 2026 a method for fingerprinting CPUs from the browser using WebAssembly SIMD. Vector operations on 128-bit registers map directly to CPU instructions (NEON on ARM, SSE/AVX on x86), and their timing reveals the actual silicon underneath, not whatever the browser claims.

The enabling primitive arrived in 2024 from Manuel at brokenbrowser.com: a one-liner that gets you a real SharedArrayBuffer on any page, no special headers, by calling new WebAssembly.Memory({shared:true}).buffer. Drive a MessageChannel ping-pong with Atomics.add() inside it and you have a counter ticking at 100,000 Hz, micro-timing precision around 6 microseconds. Chrome marked it Won't Fix.

What this defeats:
× Camoufox (Firefox C++ patches at the browser layer)
× CloakBrowser (49 Chromium binary patches)
× PatchRight, undetected-chromedriver, Nodriver, Pydoll
× Every JS prototype patch (Function.toString detection is irrelevant when nothing JS is touched)

What still works: real hardware diversity. The future of stealth scraping is real consumer machines on real ISP IPs, which is essentially what high-quality residential proxy networks like Massive, Bright Data, and Oxylabs already provide. As detection moves into the CPU layer, the value of actually being real compounds.

This is also why akamai-v3-sensor works on Akamai v3: it never executes the WASM at all because it never reaches sensor.js. By bypassing at the TLS layer, you skip every detection layer above it.

Sources: Anthony Manikhouth (DataDome) and Manuel (brokenbrowser.com).
+
Persistence / Evercookie tradition
The Cookie That Refuses to Die
Anti-bots increasingly persist tracking state across cookie clears using a chain of fallback storage: localStorage, IndexedDB, Service Workers, Cache API, FileSystem. Clear one, the others restore it. The 2010 Evercookie idea is back, in 2026 form.
💡 If clearing cookies does not reset your session, the detection layer is not in the cookie
The unclearable-cookie repo demonstrates the modern version of Samy Kamkar's 2010 Evercookie technique: when a user clears cookies in DevTools, the cookie immediately respawns from a copy held in localStorage, IndexedDB, or a Service Worker cache. The visual is hypnotic, you delete it, refresh, it is back.

Why this matters for scrapers: if you are rotating cookies between requests to look like a fresh visitor, but the target site is reading your localStorage entry from the previous session, your rotation does nothing. Anti-bot vendors like Forter and Riskified have shipped variants of this for years. Cloudflare's cf_clearance cookie now has localStorage backup in some configurations.

Storage layers a real reset has to clear:
✓ Cookies (HTTP and JS)
✓ localStorage and sessionStorage
✓ IndexedDB (every database)
✓ Service Worker registrations and Cache API entries
✓ FileSystem API (legacy but still works)
✓ Web SQL (deprecated but persists on older Chromium)
✓ ETag / If-Modified-Since headers cached at HTTP layer
✓ HSTS pin database (yes, browsing data can be encoded in HSTS pins, this is real)

Practical implication for scrapers: when you rotate sessions, do not just clear cookies. Either spin up a fresh browser profile each session (Playwright context.close() + new context, or a fresh Camoufox BrowserContext), or run in an entirely isolated container. Half-measures leak state.

For the curious: the original Evercookie by Samy Kamkar in 2010 used 13 storage mechanisms. Modern browsers have removed several (Flash LSO, Silverlight, Java applets), but added more (Service Workers, BroadcastChannel, OPFS). The trick is alive and well, just modernised.
+
Reality check · robots.txt
robots.txt Works Perfectly. On the Bots That Were Going to Comply Anyway.
A publisher blocked GPTBot, ClaudeBot, and PerplexityBot in robots.txt. Logs confirmed zero traffic from those User-Agents. The scraping continued. It just stopped identifying itself.
💡 User-Agent is a string the client chooses to send. Polite bots send a real one.
A publisher blocked GPTBot, ClaudeBot, and PerplexityBot in robots.txt. Logs confirmed it: zero traffic from any of those User-Agents. They thought they had solved the problem.

What was actually happening: the scraping continued. The traffic that used to say "I am GPTBot" was now saying "I am Chrome 124 on macOS." Same content destinations, same fetch patterns, different label.

User-Agent is a string the client chooses to send. Polite scrapers send a real one. The scrapers you are actually worried about — the ones running at commercial scale on behalf of paying customers — send whatever string gets through.

robots.txt works on:
✓ Academic crawlers (Googlebot, Bingbot, academic research bots)
✓ Large AI labs (OpenAI, Anthropic, Google) that have reputational incentives to comply
✓ Hobbyist scrapers who read the rules and care

robots.txt does not work on:
× Commercial data brokers sending Chrome User-Agents
× Competitive intelligence tools running at scale behind residential proxies
× AI startups that have not publicly announced themselves
× Anyone whose business depends on data you do not want them to have

The implication for anti-bot systems: blocking by User-Agent is the weakest possible signal. Cloudflare, Akamai, and DataDome do not read robots.txt. They score TLS fingerprints, canvas hashes, behavioural timing, and IP reputation because those signals are harder to fake. User-Agent string matching is not a detection layer. It is a flag for voluntary compliance.

For scrapers reading this: if a target blocks GPTBot in robots.txt but has no real anti-bot scoring, the robots.txt is the only gate. Respect it. If they have Akamai or Cloudflare deployed, the robots.txt is decorative. The actual gate is the JA4 hash, the canvas probe, the IP reputation check. That is where this guide comes in.

Via a publisher conversation, May 2026.
+
Ecosystem shift
Web Scraping Is Becoming Distributed Adversarial Systems Engineering
Most scraping frameworks still assume the web is static. Modern websites are adversarial runtime environments. The shift from HTML parsing to infrastructure engineering is well underway.
💡 The future of autonomous AI agents may depend on infrastructure that can operate reliably across hostile, dynamically changing web environments.
The conventional framing: web scraping is a tool for extracting data from websites.

The 2026 framing: web scraping is distributed adversarial systems engineering.

What modern infrastructure has to operate against:
• Fingerprinting systems (TLS JA4, canvas, WebGL, WASM SIMD)
• Behavioural detection (mouse physics, scroll timing, inter-request jitter)
• Anti-bot orchestration (Akamai EdgeWorker, Cloudflare Worker, DataDome middleware)
• Cloudflare interstitials and Turnstile challenges
• Dynamic runtime rendering (SPAs, hydration, lazy loading, service workers)
• Session-aware defences (trust accumulation, per-session scoring, unclearable cookies)

This is what makes tools like Scrapling architecturally interesting beyond "another Python scraper." It combines stealth browser execution, TLS fingerprint impersonation, adaptive element tracking that survives DOM changes, session-aware orchestration, proxy rotation, and MCP-based AI extraction. Not a scraper. A runtime.

The systems properties that matter now:
• Runtime orchestration (not just retries, state-aware crawl management)
• Observability (what failed, at which layer, on which request)
• Adaptive recovery (selector drift, DOM changes, anti-bot updates)
• State persistence (session trust, cookie chains, cross-request identity)
• Stealth execution (not a flag, an architecture)
• Infrastructure resilience (circuit breakers, session warmup, fallback tiers)

Once AI agents start interacting with the web autonomously at scale, reliability becomes a systems problem first and a parsing problem second. The pipeline that Firecrawl, Crawl4AI, Stagehand, and Scrapling are converging on is not "scraper plus LLM." It is a resilient extraction runtime with LLM as one processing layer among many.

Framing via D4Vinci (Scrapling author), May 2026.
+
Research · Castle Intelligence · April 2026
Your Anti-Bot Fingerprint Is Probably for Sale Right Now
Castle analysed 811 bot-adjacent sites and found browser fingerprints being collected, packaged, and sold as operational assets. 12.5% deployed fingerprinting scripts consistent with harvesting. Services openly advertise "comprehensive TLS, HTTP/2, and JavaScript fingerprint collection."
💡 Detection systems must assume replay. Client-side signals are untrusted input, not proof of identity.
Castle Research (Antoine Vastel), April 2026 analysed 811 bot-adjacent websites including proxy providers, CAPTCHA farms, engagement manipulation services, and sneaker bots. The findings document a structured, commercialised layer of the bot ecosystem that most scraping engineers have not thought about.

What they found:

12.5% of analysed sites deployed fingerprinting-related scripts consistent with harvesting. A subset replicated vendor-specific telemetry from PerimeterX, Incapsula, Akamai, Adyen, and hCaptcha, not to defend themselves, but to collect and replay the same signals against those vendors.

The mechanics:

Services like impersonate[.]pro openly advertise "comprehensive TLS, HTTP/2, HTTP/3, and JavaScript fingerprint collection." In Discord and Telegram communities, bot developers discuss embedding custom JavaScript on real websites specifically to harvest fingerprints from genuine visitors. The goal: build inventories of authentic device profiles that can be injected into automated sessions.

The PerfectCanvas mechanism from Bablosoft is the clearest example. Their documentation describes exactly the pattern:
• Render canvas on a real remote machine with a real GPU
• Send the canvas output to the automation server
• Inject it into the headless browser's response to the canvas probe

This is the harvesting-and-replay model made explicit. Instead of spoofing canvas values (detectable via inconsistency), you replay values from a real Mac. The fingerprint is genuine. It just came from a different device.

Genesis Marketplace established the precedent: ~323,000 compromised browser environments for sale, each bundled with a real device fingerprint and a custom Chromium extension that injected the victim's browser profile into attacker sessions. F5 Labs and Europol both documented this. Castle's report shows the same approach is now commercialised at scale for bot traffic, not just account takeover.

What this means for scrapers:

The arms race has a new dimension. Anti-bots are scoring fingerprints. Bot services are buying real fingerprints to replay. Defenders are now building for replay conditions, not just spoofing conditions. This is why:

• Canvas/WebGL probes are increasingly paired with behavioural and timing signals (harder to replay than static values)
• WASM SIMD CPU probes (above) are valuable precisely because they are harder to harvest and replay than JS-layer fingerprints
• Anti-bots are introducing controlled variability in their own client-side scripts so that even valid payloads can't be reverse-engineered and replayed reliably

The implication for this guide: when a stealth browser passes the canvas probe, it may not be because it spoofed the hash well. It may be because it replayed a real hash that was never flagged. The distinction matters because vendors will move toward replay-resistant probes, making the harvest-and-replay model progressively harder. WASM SIMD (which requires real hardware timing) is an early example of a replay-resistant signal.

Source: Fingerprint Harvesting in the Bot Ecosystem, Castle Research, Antoine Vastel, April 2026.
Testing tools

Check your own
fingerprint first

Before you bypass anything, you need to know what your setup is leaking. These tools show exactly what anti-bots see when your scraper connects. Run your scraper through them, not just your browser.

Gold standard, most detailed
BrowserLeaks
browserleaks.com
The most comprehensive fingerprint testing suite online. Tests WebRTC IP leak, Canvas hash, WebGL renderer, JA3/JA4 fingerprint, HTTP/2 Akamai hash, Chrome extension detection, fonts, geolocation, JavaScript environment, battery status. Essential for verifying your scraper identity stack.
TLS specific, generates JA3/JA4
BrowserLeaks TLS
browserleaks.com/tls
Tests your TLS ClientHello. Shows cipher suites, TLS extensions, key exchange groups, JA3 and JA4 hashes. Run Python requests, curl_cffi, and real Chrome through this and compare. JA4 is what Cloudflare and Akamai check at edge before serving any HTML.
IP leak, proxy coherence test
BrowserLeaks WebRTC
browserleaks.com/webrtc
Reveals your real IP even through a proxy. Shows local IP, public IP via STUN, and ICE candidates. If your proxy exit is US but WebRTC shows a local Pakistani address, every anti-bot flags you immediately. The most commonly overlooked leak.
JSON API, use directly in code
TLS JSON API
tls.browserleaks.com/json
Returns your TLS fingerprint as raw JSON including ja3, ja4, akamai hash, HTTP/2 settings. Call this directly from your scraper to compare fingerprints against real Chrome. One requests.get() vs cffi.get() tells you everything about the difference.
Quick pass/fail validation
BrowserScan
browserscan.net
Higher-level green/red check for automation detection, timezone coherence, WebRTC status, canvas fingerprint uniqueness. Good for quick pre-deployment validation before hitting a protected target.
EFF built, uniqueness score
Cover Your Tracks
coveryourtracks.eff.org
Built by the Electronic Frontier Foundation. Tells you how unique your fingerprint is among all visitors. A fingerprint too unique is as bad as one that looks like a bot. Scrapers need to look like the middle of the distribution.
Bot detection simulation
Pixelscan
pixelscan.net
Simulates what anti-fraud systems see. Identifies inconsistencies in timezone, IP, language, and WebRTC that would trigger detection. Fast pass/fail for operational teams before deploying at scale.
Advanced, behavioral and hardware signals
CreepJS
abrahamjuliot.github.io
The most advanced fingerprint tester available. Simulates what modern anti-fraud systems actually detect, including behavioral and hardware-level signals far beyond surface tests. Use this for deep audits of browser configurations.
Workflow: Fetch tls.browserleaks.com/json from both your scraper and real Chrome. Compare ja4 hashes. If they differ, fix TLS first with curl_cffi. Then check WebRTC at browserleaks.com/webrtc. Then headers. Work from layer 1 outward.
Architecture

How production scrapers
are actually built

From a single Scrapyd daemon to multi-region ECS clusters. Eleven real pipeline architectures, from simple to enterprise-scale, with every component and data flow mapped out.

The simplest production setup. One server, Scrapyd managing spiders via JSON API, ScrapydWeb as UI. Good for <50 spiders and teams without Kubernetes. Deploy with scrapyd-deployschedule via /schedule.jsonmonitor at port 6800.

💻 Developer + codebase scrapyd-deploy SCRAPYD SERVER :6800 🕷️ Scrapyd Daemon JSON API + job queue Spider 1 process Spider 2 process ↻ Rotating Proxy scrapy-rotating-proxies HTTP request 🌐 Target Site anti-bot protected 📦 Storage Pipeline SCRAPYDWEB 🖥️ Visual Dashboard port 5000 monitors via API SCHEDULER Cron / APScheduler POST /schedule.json 🔔 Slack / Email job alerts
✓ Pros
  • Zero infrastructure overhead, one server, done
  • ScrapydWeb gives full UI: logs, job history, schedule
  • Deploy new spiders in seconds with scrapyd-deploy
  • Great for teams without DevOps expertise
✗ Cons
  • Single point of failure, server down = scrapers down
  • Limited to one machine's CPU and memory
  • No auto-scaling, manual capacity planning
  • Spider isolation is process-level only
↑ Scale up

Add more Scrapyd nodes → ScrapydWeb manages cluster from one UI. Next step: scrapy-redis for shared URL queue.

Stack Scrapyd :6800ScrapydWeb :5000scrapyd-client (deploy)APScheduler or cronGerapy (alt UI)
✦ Pattern

Self-Healing Scraper
powered by Claude

Scrapy spiders break when sites change their HTML. Instead of manually fixing selectors, this architecture uses Claude to detect failures, analyse the new page structure, and write corrected selectors automatically, without human intervention.

SCRAPY SPIDER 🕷️ runs on schedule TARGET SITE 🌐 HTML changed success STORAGE 📦 S3 / DB clean items failure / empty DETECTOR Item count check 0 items = broken CLAUDE API 1. Fetch broken page HTML 2. Analyse new structure 3. Write new selectors UPDATER Patch spider config CSS / XPath / regex RETRY Re-run spider with new selectors auto-healed, spider runs again without human intervention NOTIFY Slack / email "healed" alert
1
Spider detects failure
Item count drops to zero or below threshold. A Scrapy extension hook fires immediately, no waiting for the next run.
2
Claude analyses the broken page
The full page HTML is sent to Claude with the old selectors and a prompt: "The selectors below stopped working. Examine the HTML and write corrected CSS selectors for the same data fields."
3
New selectors written and applied
Claude returns structured JSON with corrected selectors. The updater patches the spider config or YAML file. No code deployment needed.
4
Spider retries and confirms
The spider re-runs with new selectors. If items come back, healed. A Slack notification logs what changed. If it fails again, escalates to human review.
Claude prompt pattern
You are a web scraping expert. A Scrapy spider broke because the site changed its HTML.

Old selectors (no longer working):
  title:  h1.product-title::text
  price:  span.price-now::text
  image:  img.main-image::attr(src)

New page HTML (truncated):
{{ page_html[:8000] }}

Return ONLY valid JSON with corrected selectors:
{"title": "...", "price": "...", "image": "..."}
✓ Why it works
  • Claude reads raw HTML better than regex, handles minified, dynamic, and obfuscated markup
  • Zero downtime, spider heals mid-run, not on next deployment
  • Works across 50+ spiders from a single Claude integration
  • Selector changes are the most common spider failure, this covers 80% of breakages
⚙ Implementation notes
  • Use claude-haiku-3 for speed and cost, ~$0.0003 per heal
  • Cap page HTML at 8K chars before sending, beyond that Claude doesn't need more
  • Store selector history in a YAML file versioned in Git for auditability
  • Add a confidence check, if healed items look wrong, escalate to human
↑ Extend it

Add a second Claude call to validate the healed output against a schema. Use computer-use to handle JavaScript-rendered pages where HTML alone isn't enough. Log all heals to build a fine-tuning dataset.

Stack Scrapy extension hook Claude API (Haiku) YAML selector store Slack webhook Anthropic SDK
Cost & economics

Build vs buy:
the number that decides

The most common mistake is treating "can I bypass it" as the only question. The real production question is "what does each successful record cost, and is rolling my own cheaper than paying someone else." Here is the honest math, with the caveat that exact prices move constantly, so treat these as orders of magnitude, not quotes.

Self-hosted stealth stack vs managed API

ApproachMonthly cost driverRough costBest when
Self-hosted: HTTP + curl_cffi + residential proxiesProxy bandwidth (the dominant cost), small serverProxy GB at roughly 3 to 8 USD/GB, plus ~50 to 200/mo computeHigh volume on targets that yield to TLS impersonation, where you control bandwidth use
Self-hosted: Camoufox/CloakBrowser cluster + residential proxiesServer CPU/RAM for browsers, plus proxy bandwidth (browsers burn far more GB)~200 to 1,200/mo compute, plus heavy proxy GB; engineering time to maintainHardened targets that need a real browser, at volumes where per-request API fees would exceed infra cost
Managed API (ScraperAPI, Zyte, Bright Data Web Unlocker, Scrapfly)Per successful request, anti-bot handling includedRoughly 1 to 5 USD per 1,000 requests (more for JS-render / hard targets)Low-to-medium volume, or hard targets where engineering time is worth more than the per-request fee
The break-even rule of thumb: Managed APIs win until volume gets high enough that per-request fees dwarf the cost of running your own infra. A worked example: at 1 USD per 1,000 requests, 10 million requests/month is ~10,000 USD on a managed API. A self-hosted stack handling the same volume might run a few hundred in compute plus 1,000 to 3,000 in proxy bandwidth, call it 2,000 to 4,000 all-in, if you have the engineering time to build and babysit it. Below roughly 1 to 2 million requests/month, the managed API is almost always cheaper once you price in your own hours. Above 10 million, self-hosting usually wins on raw cost. In between, it depends on how hardened the target is and how much your time costs.
The cost everyone forgets: maintenance. A managed API absorbs every anti-bot change for you. A self-hosted Camoufox cluster does not, when Akamai ships a new sensor build or your fingerprint starts leaking, that is your weekend. Price your own time into the comparison. A stack that is 3,000/mo cheaper but eats four engineer-days a month is not actually cheaper. For many teams the right answer is hybrid: managed API for the hard or low-volume targets, self-hosted for the high-volume easy ones.
After the bypass

What happens to
50 million rows

Bypassing detection is the part everyone writes about. But getting the data is only the start. The questions that actually decide whether a scraping operation survives are about what you do next: where the data lands, how you avoid storing the same thing twice, and how you notice when a site quietly starts feeding you garbage.

Storage: stop dumping JSON into a folder

Format
Parquet, not CSV or JSON
For anything past a few hundred thousand rows, columnar Parquet beats row formats decisively: 5 to 10x smaller on disk through column compression, and analytics engines (Athena, DuckDB, Spark) only read the columns a query touches. A 50M-row crawl that is 40GB as JSON is often under 5GB as Parquet, and queries run an order of magnitude faster. Partition by crawl date or source so you can prune whole files without scanning them.
Layout
A simple medallion layout
Land raw responses untouched in a bronze layer (S3/GCS, exactly as scraped, your audit trail and replay source). Clean and normalise into silver (typed, deduplicated, schema-validated Parquet). Build query-ready aggregates in gold (the tables analysts and APIs actually hit). When a parser bug ships, you re-run silver from bronze without re-scraping, which on a hardened target can save you weeks and a lot of proxy spend.

Deduplication: the same item will arrive many times

URL-level
Seen-URL sets & Bloom filters
A large crawl revisits the same URL constantly through pagination loops, cross-links, and retries. Holding every seen URL in a Python set works until memory dies around a few million. A Bloom filter (or scrapy-redis's RFPDupeFilter backed by Redis) checks membership in constant memory with a tiny, tunable false-positive rate. For distributed crawls, a shared Redis set keeps every worker honest so two workers never fetch the same page.
Content-level
Hash the content, not the URL
The harder duplicate is the same product reachable via three different URLs (tracking params, locale prefixes, canonical vs vanity). URL dedup misses these. Compute a stable hash over the meaningful fields (a normalised product ID, or a hash of the cleaned record), and dedup on that. Keep a last_seen timestamp so you can tell a genuine update apart from a re-scrape, and upsert rather than blindly insert.

Data poisoning: when the bypass succeeds but the data is fake

Passing the bouncer does not mean the data is real. Sophisticated sites detect scraper-like behaviour after the initial check and respond not by blocking you but by quietly serving poisoned data: subtly wrong prices, shuffled listings, fabricated rows, or stale snapshots. You get clean 200 responses and a healthy-looking dataset that is silently corrupt. This is more dangerous than a block, because a block is obvious and poisoned data flows straight into your decisions.
Detection
How to catch poisoning
Maintain a small hand-verified ground-truth sample (a few dozen records you check manually) and diff every crawl against it. Watch for statistical anomalies: prices that are suspiciously round, distributions that shift overnight, or the same record varying between two near-simultaneous requests from different IPs. Cross-check a sample against the mobile API or a logged-in view. If two clean sessions disagree on the same field, suspect poisoning before you trust the data.
Cause
Why it happens to fast scrapers
Poisoning is usually triggered by behaviour, not fingerprint: requesting pages far faster than a human could, hitting endpoints in a non-human order, or ignoring the rendering layer entirely. The fix is the same boring discipline that prevents bans: pace requests, vary timing, follow realistic navigation paths, and do not request the whole catalogue in five minutes. Slow, human-shaped scraping gets real data; greedy scraping gets fed lies.
Mobile API Scraping

Intercept mobile app traffic
before it hits any anti-bot

Mobile APIs serve the same data as the web, but with weaker protection. No Cloudflare, no JA4 fingerprinting. Intercept the traffic once, replicate the call forever.

Why mobile APIs? The same data served to a mobile app often sits behind a simpler auth layer than the web. No browser fingerprinting, just a clean JSON endpoint you can call directly from Python.
01
Install Android Studio + create a Virtual Device
Open Android Studio → Virtual Device Manager → Create Device. Pick any phone that shows the Play Store icon. For the system image, choose any API level above 28do not choose Android 9 (Pie / API 28), the rooting script does not support it. API 30 (Android 11) is a safe default.
💡 Any Android 10+ image works. Start the AVD and confirm it boots before proceeding.
02
Root the AVD using rootAVD
AVDs are not rooted by default. Root access lets HTTP Toolkit intercept SSL traffic. The rootAVD script handles everything in one command.
git clone https://github.com/newbit1/rootAVD.git
cd rootAVD

# Verify AVD is accessible
adb shell

# List your AVDs
./rootAVD.sh ListAllAVDs

# Copy the first command from the output and run it
# e.g: ./rootAVD.sh system-images/android-30/google_apis_playstore/x86_64/ramdisk.img
💡 adb not found? Add to ~/.zshrc: alias adb='/Users/$USER/Library/Android/sdk/platform-tools/adb'
03
Confirm root, Magisk appears in the app drawer
After rootAVD finishes the AVD reboots automatically. Once it's back up, open the app drawer and look for the Magisk app, this confirms root is working. Zygisk does not need to be enabled.
💡 If the AVD didn't reboot itself, reboot it manually. No Magisk = root failed, re-run the script.
04
Install HTTP Toolkit and connect via ADB
Download from httptoolkit.com or install via Homebrew. Open it → Intercept tab → "Android device via ADB". HTTP Toolkit detects your running AVD and prompts it to grant superuser rights, grant it.
# macOS
brew install --cask http-toolkit
💡 "System trust disabled" warning? Disconnect and reconnect in HTTP Toolkit, or reboot the AVD.
05
Install the target app and capture its requests
Sign into Google Play on the AVD and install the app, or download the APK from apk.support and drag-drop it onto the emulator. Open the app, navigate through it (lists, detail pages, search) while HTTP Toolkit runs. Switch to the View tabevery request the app makes is captured in real time.
💡 Use the filter bar, you'll see 400+ requests but only ~10 are the data endpoints. Filter by the target domain name.
06
Replicate the API call in Python
Click any intercepted request to see full headers, auth tokens, and query parameters. Test in Postman first to confirm it returns data, then replicate in Python. Mobile APIs return clean JSON, no HTML parsing needed.
import curl_cffi.requests as requests

resp = requests.get(
    "https://api.targetapp.com/v2/listings",
    headers={
        "Authorization": "Bearer <token_from_http_toolkit>",
        "X-App-Version": "4.2.1",
        "User-Agent": "TargetApp/4.2.1 (Android 11; SDK 30)",
        "Accept": "application/json",
    },
    impersonate="chrome120"
)
data = resp.json()
💡 Tokens expire, check if the app refreshes on login and build a token refresh step into your scraper.
✓ Works well for
  • Property portals, classifieds, marketplaces
  • Apps where the web version is heavily protected
  • Data only available in the mobile app
  • Targets using simple Bearer token auth
  • Any app that doesn't pin SSL certificates
✗ Limitations
  • Apps with SSL pinning block interception
  • Some apps crash on rooted devices
  • ARM-only apps may not run on x86 emulators
  • Tokens expire, need refresh logic in scraper
  • App updates can silently change endpoints
↑ SSL Pinning bypass

If the app blocks interception it likely uses SSL pinning. Use Frida or objection to bypass it at runtime, or use Burp Suite with the Xposed + TrustMeAlready module for a more permanent bypass.

Stack Android Studio rootAVD (github.com/newbit1/rootAVD) Magisk HTTP Toolkit apk.support Postman curl_cffi
Plain English

Scraping jargon
in simple terms

Every term that makes scraping documentation confusing, explained with an analogy.

Network layer
TLS Fingerprint
How your browser "shakes hands" when connecting securely. Chrome and Firefox shake hands differently, so a server can tell them apart before you send a single header. Analogy: recognising someone by the way they shake hands, firm, soft, awkward.
Network layer
HTTP Fingerprint
The order and style of your HTTP headers. A bot might say "I'm Chrome" but forget to include headers Chrome always sends. Analogy: like a boarding pass, if your name and flight number don't match the expected pattern, it's suspicious.
Network layer
TCP/IP Fingerprint
Looks at how your computer sends and receives internet packets. Windows and Linux send packets with subtle differences. Analogy: recognising someone's hometown by their accent, you didn't ask, they just gave it away by how they talk.
Browser layer
Canvas Fingerprint
Website secretly asks your browser to draw a hidden picture. Each GPU renders it slightly differently, that difference is your fingerprint. Analogy: asking 10 artists to draw the same tree, each drawing is unique even with the same instructions.
Browser layer
WebGL Fingerprint
Uses 3D graphics rendering to identify your GPU and driver. Same browser, different hardware, different fingerprint. Analogy: recognising a car engine by its sound, same model, but each engine has subtle variations you can hear.
Browser layer
Device Fingerprint
Collects OS, fonts, screen size, timezone, plugins, battery level, everything about your setup combined into a unique profile. Analogy: identifying someone by their full outfit + hairstyle + voice + habits. Change one thing, the combo is still unique.
Behavioural
Behavioural Analysis
Watching how you type, scroll, move your mouse. Bots move in straight lines at constant speed. Humans are messy and inconsistent. DataDome runs 35 behavioural signals in real-time. Analogy: a security guard watching body language, not what you say, how you move.
Challenge
Dynamic Challenges
The website throws mini-tests to check if you're real, CAPTCHA, Turnstile, proof-of-work puzzles. Kasada changes them constantly so you can't pre-solve. Analogy: a teacher changing exam questions mid-test to catch cheaters.
Network
IP Reputation
Whether your IP address is associated with known bots, VPNs, datacenters, or abuse. Datacenter IPs are instantly flagged. Residential IPs from real ISPs get highest trust. Analogy: your home address appearing on a blacklist, the doorman knows before you knock.
Compliance signal
robots.txt
A text file at /robots.txt telling crawlers which paths to skip. Works on voluntary compliance only. Googlebot and GPTBot respect it. Commercial scrapers send a Chrome User-Agent and walk straight past it. Analogy: a "staff only" sign. Anyone who cares about signs obeys it. Anyone who does not care walks in anyway.
Community

Where scrapers
talk to each other

The best scraping techniques rarely come from documentation, they come from people who've already hit the same wall you're hitting. These communities are where the real knowledge lives.

Discord servers

Recommended ★
The Web Scraping Club
Pierluigi Vinciguerra
The community behind the best scraping newsletter. Anti-bot discussions, real-world bypasses, tool comparisons. Active and high-signal. Recommended first stop.
Official · Experts on call · 4,600+ members
Oxylabs
discord.com/invite/DffyvAcg2w
Live Q&As with Oxylabs in-house engineers, webinars on proxies and anti-bots, OxyCon conference channel, and exclusive product discounts. Self-described as "#1 community for all things web scraping." Strong on practical bypass questions and proxy strategy. Active staff presence makes it a useful place to surface real production issues.
Zyte-powered · Annual summit
Extract Data Community
discord.gg/extractdata
One of the largest web scraping servers. Powered by Zyte. Associated with the annual Extract Summit conference. Thousands of members, high-activity channels.
Anti-bot experts · Reverse engineers
Scraping Enthusiasts
Anti-bot reverse engineering focus
Home of puppeteer-extra-plugin-stealth maintainers. Community bots that detect anti-bot software, find hidden API endpoints, and monitor anti-bot updates. Best server for hard targets.
Python · Node.js · Production
Scraping In Prod
General web scraping questions
General scraping questions, site-specific help, anti-bot discussions. Python and Node.js focused. Good place to ask about specific websites or frameworks.
Official Scrapy · Framework experts
Scrapy Official
Scrapy core maintainers active
Official Scrapy community. Core maintainers are active daily. Best place for Scrapy-specific questions, extensions, architecture advice, and code reviews.

Reddit communities

Newsletters worth reading

Resources from The Web Scraping Club

YouTube channels worth following

09 The arms race

From IP bans
to transformer ML

Every bypass technique was born as a direct response to a specific detection innovation. The escalation explains why each tool exists.

2004
Selenium born for QA testing. WebDriver protocol. Zero anti-bot thinking, scraping wasn't a threat concept yet.
2017
Puppeteer launches. First CDP Chrome automation. Anti-bots respond with IP reputation + User-Agent checks. Defeated by: proxy rotation + fake UA strings.
2018–2020
JS fingerprinting era. Canvas hash, WebGL, navigator.webdriver=true. playwright-stealth emerges. Playwright 2020, Microsoft, cross-browser. F5 acquires Shape Security for $1 billion.
2021–2022
TLS fingerprinting mainstream. JA3 at CDN edges. Python httpx identified by hash. curl_cffi emerges. DataDome + Akamai add behavioural scoring. PerimeterX + HUMAN Security mergecreating 29,650-site network.
2023–2024
JA4+ standardisation. Cloudflare Rust crate. Chrome randomises extensions, breaks JA3. Camoufox and CloakBrowser emerge as first C++ binary solutions. DataDome WASM boring_challenge. Scrapling 38K stars.
2025
ML + OS-level signals. HTTP/2 SETTINGS frames. TCP TTL. Transformer ML on micro-timing at <1ms. DataDome 85K models. Browserbase $40M at $300M valuation. Firecrawl 60K stars. ScrapingBee acquired by Oxylabs.
2026
C++ binary patches are the baseline. JS injection obsolete, toString() exposes all patches. Camoufox 100% pass rate. Firecrawl 111K stars. webclaw Rust + 10 MCP tools. JA4+ universal. Market: $7.5B → $38B by 2034. The arms race is AI vs AI.
★ You made it

Thank you for reading.

This is everything I know about web scraping in 2026, every detection layer, every anti-bot system, every library, every architecture I've actually built or used in production over the last seven years.

If even one section saved you a late night of debugging, that's why I wrote it.

Build something interesting with this. And if you do, I'd genuinely love to hear about it.

Asad Ikram
Data Engineer · Scraping specialist · Lahore, PK