Browser fingerprinting
Browser fingerprinting collects canvas, WebGL, fonts, hardware, and TLS signals to identify a browser uniquely. Bot-shields use it to score every request.
Definition
Browser fingerprinting is the practice of identifying a browser by combining low-entropy signals — TLS handshake (JA3/JA4), canvas/WebGL render output, installed fonts, hardware concurrency, screen dimensions, time zone, language, plugins, and navigator entropy — into a stable identifier. Bot-shields (Cloudflare, DataDome, PerimeterX, Kasada) score requests by comparing the fingerprint against known-bot patterns and known-good browser baselines.
How it works
A JS challenge collects the signals client-side and posts them (or a hashed digest) to the bot-shield. On the server side, the TLS layer captures JA3/JA4 from the ClientHello before any HTTP is parsed. The shield combines both into a fingerprint hash, looks it up against its training corpus, and emits a score. Low-entropy fingerprints (default Playwright, Selenium with vanilla Chrome) match known-bot clusters and get downscored. High-entropy fingerprints with consistent signals (real human browsers) pass.
Where you see it
Behind every CAPTCHA scoring layer, every Cloudflare-fronted site, every anti-fraud system at banks/airlines/ticketing. Your scraper's fingerprint determines whether you get challenged or pass silently.
Frequently asked questions
Yes but be careful — naive randomization produces impossible combinations (Windows kernel with macOS fonts) that score worse than a single consistent fingerprint. Use real-browser fingerprint pools or tools like curl-impersonate / undetected-chromedriver.
It fixes the IP-reputation signal but not the JS/TLS fingerprint. Both layers must match — a clean IP with a leaky fingerprint still gets flagged.
JA3 fingerprints the TLS ClientHello (cipher suites, extensions, curves). JA4 is the newer 2023 spec that adds resilience to TLS 1.3 randomization and provides separate hashes for HTTP versions. Cloudflare and others use both.