Skip to main content

Webparsers.com

Webparsers Homepage
Login
Menu
Menu
Login

Bypass FingerprintJS Detection

7 min read

Table of Contents

Browser Fingerprinting in Bot Detection: How FingerprintJS Works and What Pipelines Must Address

Browser fingerprinting is not one technology — it is a collection of techniques that combine dozens of device and browser attributes into a unique identifier. FingerprintJS is the most widely deployed fingerprinting library, used both for user identification and, in its Pro version, for bot detection. Understanding how fingerprinting works at the attribute level is foundational to building scraping pipelines that produce fingerprints indistinguishable from real devices.

This article covers what browser fingerprinting collects, how FingerprintJS’s bot detection specifically works, which attributes headless browsers fail on by default, and what production pipelines must configure to produce realistic fingerprints. For structured data from fingerprint-protected sources, see our API Marketplace. Fingerprinting is a component of most systems covered in this cluster — see our articles on Akamai, DataDome, and Cloudflare.

Talk to a Scraping Engineer

What Browser Fingerprinting Collects

Attribute category Specific attributes Headless browser default issue
Automation flags navigator.webdriver, chrome.runtime, window.Selenium, __nightmare navigator.webdriver = true in default headless Chrome; others may be present
Canvas fingerprint 2D canvas rendering output hash; varies by GPU, OS, browser version Headless servers produce GPU-less rendering — distinctive hash values clustering by server hardware
WebGL fingerprint Renderer string, vendor string, WebGL rendering output, supported extensions Server GPU (or software renderer) differs from consumer device GPU — distinctive renderer strings
Audio fingerprint Web Audio API oscillator output values; device-specific rendering Headless environments produce default or zero audio context values that cluster distinctively
Screen and viewport Screen resolution, color depth, pixel ratio, available dimensions, viewport size Default headless viewport (800×600 or non-standard) inconsistent with real device usage
Hardware indicators navigator.hardwareConcurrency, navigator.deviceMemory, battery API Server hardware values (high CPU count, large memory) inconsistent with consumer devices
Installed fonts Font enumeration via canvas rendering or CSS measurement Server OS lacks consumer fonts; missing standard fonts (Arial, Times New Roman) is anomalous
TLS fingerprint JA3/JA4 hash of TLS ClientHello parameters HTTP libraries produce TLS fingerprints distinct from browser TLS stacks

Why Patching navigator.webdriver Is Not Enough

Patching navigator.webdriver to false is the most common anti-detection measure applied to headless browsers, and it is entirely insufficient on its own. Fingerprint analysis systems do not rely on a single flag — they look for the internal consistency of the full fingerprint:

  • Canvas output must match the declared GPU. A fingerprint that claims an NVIDIA GPU (via WebGL renderer string) but produces canvas hash values consistent with a software renderer is internally inconsistent. Real devices produce canvas values that correlate with their GPU.
  • Screen dimensions must be plausible. A 1920×1080 screen dimension with a default 800px viewport, zero pixel ratio, and no touch capability is internally inconsistent with a real laptop or desktop. Each screen attribute must form a coherent device profile.
  • Hardware concurrency must match device class. navigator.hardwareConcurrency returning 32 (a server CPU count) on a device claiming to be a consumer laptop is anomalous. Real consumer laptops have 4–16 cores; values outside this range for laptop user agents are suspicious.
  • Missing APIs are signals. Real browsers have consistent sets of APIs available. A browser missing the Notification API, lacking WebRTC internals, or presenting other API gaps that real Chrome would not have is identifiable as modified.
  • Consistency across the full attribute set matters most. FingerprintJS Pro’s bot detection specifically looks for internal inconsistencies across the full collected attribute set — not just individual anomalous values.

What Production Pipelines Must Configure

  • GPU-consistent canvas and WebGL values. Configure the headless browser to use a software renderer that produces values consistent with common consumer GPUs, or use a machine with a real GPU and configure WebGL to expose plausible consumer GPU identifiers.
  • Consistent screen and viewport configuration. Set viewport to a common resolution (1920×1080, 1366×768, 1440×900), configure screen properties consistently, and ensure pixel ratio and color depth match the declared display profile.
  • Font set matching the declared OS. Install or simulate the standard system fonts for the declared OS. A Windows user agent with no Windows system fonts is immediately anomalous.
  • Hardware values appropriate to declared device class. Set hardwareConcurrency and deviceMemory to values consistent with a typical consumer device for the declared user agent — not server-class values.
  • TLS fingerprint matching. Use a browser-native TLS stack or configure the connection to produce a JA3/JA4 hash consistent with the declared browser version. See our article on headless browser tools for implementation approaches.

How Webparsers Handles Fingerprint-Based Detection

  1. We build complete, internally consistent device profiles. Our browser configurations for fingerprint-sensitive targets are validated for internal consistency across all attribute categories — not just the obvious automation flags. Canvas output, WebGL values, screen properties, hardware signals, and font sets are all configured to form a coherent, realistic device profile.
  2. We configure device profiles appropriate to each target’s user base. A US e-commerce site should be accessed from a profile that matches common US consumer device configurations. A mobile-first app should be accessed with a mobile profile. Device profile selection is part of per-source configuration.
  3. We rotate device profiles while maintaining per-session consistency. Different sessions use different device profiles; within a session, the profile does not change. FingerprintJS detects fingerprint changes within a session as anomalous.
  4. We address fingerprinting as an infrastructure concern across all anti-bot systems. Fingerprint quality affects Cloudflare, Akamai, DataDome, Human Security, and GeeTest equally — it is not a FingerprintJS-specific issue. Our collection infrastructure’s fingerprint configuration addresses all systems that rely on it.
  5. Data from fingerprint-protected sources is available through our API Marketplace. See API Marketplace.

Discuss Your Fingerprint-Protected Source Requirements

Frequently Asked Questions

What is FingerprintJS and how does it detect bots?

FingerprintJS is a browser fingerprinting library that generates visitor identifiers from browser and device attributes. The Pro version adds bot detection capabilities, identifying automation by checking for navigator.webdriver, headless browser signatures, inconsistent fingerprint attributes, and known automation tool characteristics. It is embedded in many sites’ analytics and bot protection stacks — encountering FingerprintJS does not mean a site has dedicated bot detection, but it does mean fingerprint quality matters for consistent access.

Can FingerprintJS fingerprints be spoofed?

Individual attributes can be overridden, but producing an internally consistent fingerprint indistinguishable from a real device requires configuring every attribute to form a coherent device profile. Canvas output must match the declared GPU; screen dimensions must match hardware; font sets must match the OS; hardware values must match the device class. Inconsistencies across attributes are what detection systems identify — not individual anomalous values in isolation. Production-grade fingerprint spoofing is a systematic engineering effort, not a single patch.

How does FingerprintJS Pro differ from the open-source version?

The open-source FingerprintJS collects fingerprint signals and produces a visitor identifier — it is designed for analytics and user identification. FingerprintJS Pro (now marketed as Fingerprint) is a commercial product that adds bot detection signals, incognito mode detection, tampering detection, and confidence scores to the visitor identifier. In bot protection contexts, sites use Fingerprint Pro specifically for its bot detection signals rather than just the visitor ID.

Does TLS fingerprinting affect scraping even when using a headless browser?

Yes. TLS fingerprinting (JA3/JA4) happens at the connection level, before any HTTP or JavaScript is exchanged. Even a headless browser that perfectly spoofs all JavaScript-accessible properties may produce a TLS handshake fingerprint that differs from the real browser it is impersonating — because the TLS parameters are determined by the underlying TLS library, not the JavaScript environment. Matching the TLS fingerprint requires either using the browser’s native TLS stack or routing through a proxy that normalizes TLS characteristics to match the declared browser.