Writing the article directly.
Most HTTP clients get blocked not because of their IP address but because their TLS fingerprint is wrong. curl-impersonate solves this by patching libcurl to replicate the exact TLS handshake — cipher suites, extension order, GREASE values, and all — that Chrome or Firefox would send. in 2026, with JA3/JA4 fingerprint detection baked into every major bot-protection vendor, getting this right is no longer optional for serious scraping work.
what curl-impersonate actually does
standard curl uses OpenSSL with a default cipher list and a predictable extension order. any TLS inspection proxy — Cloudflare, Akamai, Imperva — sees that pattern immediately and scores it as non-browser traffic. curl-impersonate replaces the TLS stack (BoringSSL for Chrome targets, NSS for Firefox targets) and injects the browser’s exact ClientHello parameters at compile time.
the result is a binary that behaves like curl at the API level but presents as a real browser at the TLS layer. this means:
- cipher suite order matches the target browser version exactly
- TLS extensions appear in the correct sequence, including padding and session ticket
- GREASE values (RFC 8701 reserved bytes) are inserted where Chrome inserts them
- ALPN negotiation advertises h2 before http/1.1 as browsers do
- HTTP/2 SETTINGS frames mirror the browser’s frame order and window sizes
supported browser targets in 2026
curl-impersonate ships pre-built binaries for a fixed set of browser profiles. as of mid-2026 the maintained profiles are:
| profile | underlying TLS lib | http/2 | notes |
|---|---|---|---|
| chrome116 | BoringSSL | yes | stable, most widely deployed |
| chrome124 | BoringSSL | yes | updated GREASE pattern |
| chrome131 | BoringSSL | yes | latest as of Q1 2026 |
| firefox117 | NSS | yes | includes Firefox-specific ext order |
| firefox124 | NSS | yes | current ESR baseline |
| safari17 | SecureTransport sim | yes | community fork, less maintained |
for most production scrapers targeting Cloudflare-protected sites, chrome124 or chrome131 is the correct default. sites running F5 Shape Security often check HTTP/2 pseudo-header order as a secondary signal on top of TLS, so the full chrome131 profile beats chrome116 in those environments.
basic usage and python integration
the simplest invocation replaces your curl call with the browser-specific binary:
# install via the pre-built release
curl -L https://github.com/lwthiker/curl-impersonate/releases/download/v0.6.1/curl-impersonate-chrome.x86_64-linux-gnu.tar.gz | tar xz
./curl_chrome131 -H "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
https://target.com/api/productsfor python scrapers, the curl_cffi library wraps curl-impersonate and exposes a requests-compatible interface:
from curl_cffi import requests
session = requests.Session()
resp = session.get(
"https://target.com/api/products",
impersonate="chrome131",
proxies={"https": "http://user:pass@proxy-host:8080"},
timeout=30,
)
print(resp.status_code, len(resp.text))curl_cffi is the recommended approach for 2026 production work. it handles cookie jars, redirect following, and proxy routing with the same ergonomics as requests, while keeping the BoringSSL fingerprint intact. avoid the older requests-impersonate wrapper — it has not kept pace with browser profile updates.
where curl-impersonate falls short
TLS mimicry handles one detection layer, not all of them. understanding the gaps matters more than understanding the tool itself.
what it fixes: JA3/JA4 hash matches, cipher suite scoring, GREASE pattern checks, HTTP/2 framing order. sites that purely fingerprint the TLS ClientHello will stop blocking you.
what it does not fix:
- javascript fingerprinting — canvas, WebGL, font enumeration, navigator properties. curl-impersonate does not run JS.
- behavioral signals — mouse movement patterns, scroll velocity, time-on-page. headless browser detection like Distil Networks / Imperva scores these heavily.
- IP reputation — a clean TLS fingerprint from a datacenter /24 still fails Cloudflare’s IP scoring layer.
- cookie challenges — Cloudflare Turnstile and similar challenges require a real JS environment to solve.
- TLS fingerprint rotation — some vendors (Akamai Bot Manager v4+) track fingerprint consistency across sessions and flag accounts that switch profiles mid-session.
for sites that layer JS challenges on top of TLS checks, the correct architecture is curl-impersonate for the initial unauthenticated crawl, plus a headless browser pool (Playwright + stealth) for pages behind challenge walls. see the browser fingerprint configuration guide for how to structure both layers together.
deploying at scale
running curl-impersonate in a distributed scraping pipeline has a few operational wrinkles worth knowing before you hit production:
- binary distribution — each scraper node needs the correct binary for its architecture. x86_64 linux is the common case; arm64 (AWS Graviton, Mac M-series dev machines) needs a separate build or a QEMU layer.
- proxy compatibility — curl-impersonate respects
HTTPS_PROXYand--proxyflags normally. route through residential or mobile proxies for best results; the TLS fix alone does not rescue datacenter IPs. - concurrency model —
curl_cffisessions are not thread-safe. use one session per thread or switch to asyncio withcurl_cffi.AsyncSession. - profile freshness — browser TLS parameters change with each major release. pin to a profile version in your dependency lockfile and schedule quarterly profile audits when new Chrome stable releases ship.
- logging and fingerprint drift — log the JA4 hash of outbound connections in staging using a local mitmproxy to verify the fingerprint matches the claimed profile before deploying to production.
a lightweight monitoring setup catches profile drift early and prevents silent degradation as targets update their detection rules.
bottom line
curl-impersonate is the right tool for eliminating TLS-layer bot detection in 2026, and curl_cffi makes it production-ready in Python with minimal overhead. it is not a full anti-detect stack — pair it with residential proxies and a stealth headless layer for JS-heavy targets. dataresearchtools.com covers the full detection surface across TLS, browser, behavioral, and CAPTCHA layers if you need to go deeper on any one piece.
Related guides on dataresearchtools.com
- Cloudflare Turnstile vs hCaptcha vs reCAPTCHA Enterprise: Which Bypass Path?
- How JA3 vs JA4 vs JA4+ Fingerprints Differ and How to Spoof Them (2026)
- How to Bypass F5 Shape Security for Web Scraping (2026)
- How to Bypass Distil Networks (Imperva Bot Protection) in 2026
- Pillar: Browser Fingerprint Configuration: Anti-Detect Setup Guide 2026