Device Fingerprinting and How to Bypass it

Alejandro Loyola
Alejandro Loyola
Technical Support · January 15, 2026

Introduction

If you're doing any serious browser automation in 2026 – whether it's scraping, QA, or internal tooling – you're likely to have already run into invisible walls: Cloudflare interstitials, sudden 403s, or flows that only break in headless mode.

A big part of that is fingerprinting, often referred to as device fingerprinting – though there are other methods.

Modern anti-bot and fraud systems don't just look at your IP address or cookies. They build a digital fingerprint of the user's browser, device, Transport Layer Security (TLS) stack, and behavior using dozens of data points – from screen resolution and system fonts to GPU timing and TLS cipher ordering.

In this guide, you'll:

  • Get a clear mental model of browser, device, TLS, TNS, and behavioral fingerprinting.
  • See who actually uses these techniques and why.
  • Learn practical, code-level approaches to reducing fingerprint-based blocks in Playwright and Puppeteer – with a focus on using Browserless as the "managed, production-grade" layer.
  • Understand the limits, legal considerations, and when you should not try to bypass fingerprinting.

We'll stay on the right side of the law: everything here is aimed at testing your own systems, building reliable automation, or accessing data in ways that respect site terms and regulatory constraints.

What is a fingerprint?

A fingerprint is just a unique (or almost-unique) combination of attributes that can be tied back to a user's device, browser, or connection.

In a browser context, that can include:

  • HTTP-level data – User-Agent, Accept-Language, IP address and geo, HTTP/2 vs. HTTP/1.1, ALPN.
  • JavaScript API data – navigator properties, screen.width or screen.height (screen resolution), time zone, deviceMemory, hardwareConcurrency, and touch support.
  • Environment and content APIs – canvas fingerprinting, WebGL renderer, audio stack, supported video codecs.
  • Installed components – browser plugins or extensions, system fonts, and sometimes even hardware components exposed through performance quirks.

None of these on their own is very identifying. But together they form a digital fingerprint that can reliably distinguish one user's browser from millions of others. Studies have found that a large fraction of desktop devices can be uniquely identified this way.

In a broader sense, you also get:

  • A machine fingerprint – based on hardware configuration and software configurations on a remote computing device.
  • A device fingerprint – a persistent identifier across browsers and apps on the same device.
  • A behavioral fingerprint – patterns in how a user interacts with the page.

All of this can be used to improve customer experience and prevent fraud, or for aggressive online tracking that privacy advocates are rightly unhappy about.

What is fingerprinting?

Fingerprinting is the act of collecting and correlating those attributes on the user side – not necessarily with explicit consent – to generate a stable, unique identifier (a "user's fingerprint") from the data collected.

Typically, fingerprinting works like this in a web browser:

  1. A script runs in the web browser, often from a third-party domain.
  2. It queries dozens of device attributes – browser type and browser version, operating system type and version, system fonts, installed fonts, supported codecs, canvas rendering output, screen resolution, installed plugins, etc.
  3. It combines all these data points – plus IP address, headers, and sometimes previous device IDs – into a compact, unique ID.
  4. That unique identifier is stored server-side and linked to fraud detection rules, personalization, or online tracking profiles.

The key difference from cookies is that nothing needs to be stored on the device. Even in incognito mode or with cookies cleared, the same combination of device data will often re-generate the same fingerprint.

Different types of fingerprinting and how they work

Browser fingerprinting

Browser fingerprinting focuses on attributes exposed by the browser itself – both HTTP headers and JavaScript APIs.

Typical browser fingerprinting techniques look at:

  • User-Agent and client hints (Sec-CH-UA-*).
  • Screen resolution and color depth.
  • Time zone, locale, and Accept-Language.
  • System fonts / installed fonts (via measurement hacks).
  • WebGL renderer, GPU capabilities, and canvas fingerprinting output.
  • Audio and video capabilities (codecs, sample rates).
  • Touch and pointer support, platform or OS string, and input devices.
  • The presence or absence of browser plugins and extensions.

Tools like AmIUnique, EFF's Cover Your Tracks, CreepJS, and commercial SDKs demonstrate how much information collected from a single page load can uniquely identify a user's browser.

Modern setups go even further:

  • They incorporate machine learning models that take a large number of data points and learn which combinations are most discriminative.
  • They combine browser fingerprinting with TLS and behavioral signals into a complete picture of the user.

For you as an automation engineer, this means a default headless Playwright or Puppeteer browser with obvious markers (HeadlessChrome, navigator.webdriver, missing plugins, unusual WebGL info) is easy to identify.

Device fingerprinting

Device fingerprinting zooms out from the user's browser to the user's device.

Instead of focusing only on browser attributes, device fingerprinting solutions combine:

  • Browser type, browser version, and web browser settings.
  • Operating system and OS version.
  • Hardware components and hardware configuration – CPU, GPU, memory, and some device attributes.
  • Network attributes – IP address, ASN, connection type, mobile vs fixed, sometimes Wi-Fi vs cellular hints.
  • Cross-device fingerprinting data – associating multiple devices to the same user through shared logins and behavior.
  • Device IDs exposed by mobile apps or SDKs on mobile devices and connected devices.

Commercial providers like Fingerprint, Arkose Labs, IPQS, and Stytch use these signals to create a stable, unique identifier per device and feed it into risk scoring, fraud detection, and preventing unauthorized access.

So, ultimately, how does device fingerprinting work as a reliable way to recognize the same device across multiple sessions, browsers, and sometimes even apps?

Because it's based on hardware and software configurations rather than a single cookie, the fingerprint often stays stable for months even if the user changes browsers, uses incognito mode, or hides behind a VPN.

TLS fingerprinting

TLS fingerprinting looks at the encrypted connection itself, not the browser APIs. When a client connects to a server over HTTPS, it performs a TLS handshake. The first message (ClientHello) includes:

  • Supported TLS versions.
  • Supported cipher suites and their ordering.
  • Supported "groups" (elliptic curves) and point formats.
  • Extensions like SNI and ALPN.

Taken together, this sequence forms a TLS fingerprint that can accurately determine whether the client is Chrome on Windows, Safari on iOS, Python requests, curl, a specific bot, or something else.

Common schemes:

  • JA3 – hashes version, cipher suites, extensions, curves, and point formats from the ClientHello into a single MD5 string.
  • JA4 – a newer scheme that stabilizes fingerprints even when extension order is randomized and adds more HTTP and QUIC context.

Anti-bot vendors and CDNs (Cloudflare, Akamai, DataDome, etc.) maintain large databases of JA3/JA4 fingerprints:

  • A "normal" Chrome 122 on Windows 10 fingerprint will be allowlisted.
  • A "Python requests 2.x with OpenSSL defaults" machine fingerprint is very likely to be blocked, even if you spoof every HTTP header perfectly.

The key point: TLS fingerprinting triggers before any HTTP headers or JavaScript run, so you can't bypass it by just tweaking browser fingerprinting techniques at the application layer.

TNS fingerprinting

TNS fingerprinting is more niche in web automation, but worth understanding.

TNS stands for Transparent Network Substrate, a proprietary Oracle protocol used for Oracle database client–server communication.

Security teams and scanning tools can fingerprint:

  • The structure and fields of TNS handshake packets
  • Banner responses from TNS listeners
  • Supported options and protocol quirks

From those, they can identify Oracle versions, configurations, and sometimes vulnerable setups from the outside, without logging into the database itself. This fingerprinting isn't something your Playwright or Puppeteer stack typically touches, but it's another example of protocol-level fingerprinting where low-level handshakes create a unique fingerprint.

Behavioral fingerprinting

Behavioral fingerprinting focuses on what the user does, not what the device is. Signals can include:

  • Mouse movements, scroll patterns, and keypress timings.
  • How quickly elements are clicked after they appear.
  • Timing distributions between navigation, network calls, and DOM interactions.
  • Gesture patterns on mobile devices.

Researchers and vendors use machine learning to learn patterns that distinguish humans from automation, and genuine users from fraudsters, by looking at these events over time.

In practice:

  • A script that scrolls exactly one viewport at perfectly regular intervals from the same device configuration is trivial to flag.
  • A human-like pattern – small jitters in mouse movements, natural pauses during reading, varying click positions within a button – is much harder to classify as a bot.

Behavioral fingerprints are often combined with browser, device, and TLS fingerprints into one risk score.

Who uses fingerprinting?

Fingerprinting isn't only an ad-tech trick, it underpins a lot of modern security and fraud prevention infrastructure.

Some common use cases:

Advertising and analytics

Ad platforms and trackers use browser fingerprinting and device fingerprinting to:

  • Track users across websites even when cookies are blocked.
  • Build profiles of users' preferences and behavior.
  • Attribute conversions across different devices and browsers.

Fraud detection and risk scoring

Fraud teams rely heavily on device fingerprint trackers to:

  • Detect account takeovers by noticing logins from new devices versus the same device.
  • Link multiple devices or multiple accounts controlled by the same fraudster.
  • Spot emulator farms, device spoofing, and suspicious virtual machines.
  • Analyze bot and human behavior to improve their fingerprinting algorithms.

Account security and abuse prevention

Platforms use fingerprinting to:

  • Flag unusual logins or payment attempts from previously unseen hardware and software configurations.
  • Enforce limits on the number of accounts tied to an individual device.
  • Preventing fraud in gaming, marketplaces, healthcare, and financial services by blocking abusive devices or requiring additional verification.

Regulatory and compliance use cases

In some industries, device fingerprinting helps:

  • Detect the automated scraping of regulated content.
  • Enforce per-user access limits.
  • Provide evidence of suspicious activity from individual devices during investigations.

Again, all of this is lawful only when done under appropriate legal bases (GDPR, CCPA, etc.) – which is why you should talk to legal if you're considering rolling out your own device fingerprinting.

How to bypass browser fingerprint detection

Let's shift to the part you're probably most interested in: making Playwright and Puppeteer less obvious when you're doing legitimate automation.

First, a reality check:

  • You can't make your automation invisible – the goal is to blend into normal traffic, not to create a one-off, unique fingerprint.
  • Every layer has to line up – TLS fingerprint, HTTP headers, JavaScript environment, stored state, and behavior.

Also, remember that, even with perfect engineering, you still have legal and ToS boundaries. Bypassing technical protections to scrape someone else's site may breach their terms and, in some jurisdictions, computer misuse laws. A practical approach is:

  1. Use real browsers (Playwright or Puppeteer) to inherit realistic TLS and browser fingerprints.
  2. Use a managed platform like Browserless to handle low-level fingerprint, proxy, and CAPTCHA issues at the CDP layer.
  3. Tune your browser context so your device data, user agent, and operating system look like a plausible, single user's device configuration.

Let's look at some of the concrete setups.

Bypass fingerprint detection in Playwright – with Browserless

With Playwright, your best move is to:

  • Run a real Chromium instance via CDP.
  • Configure a realistic browser context (user agent, viewport, time zone, locale, permissions).
  • Keep sessions and cookies consistent so your "user" looks like the same device over time.

Browserless gives you a remote Chrome running on real hardware with tuned launch flags. You connect over WebSocket using connectOverCDP.

A minimal Node.js example:

The key points of this script:

TLS fingerprint

Because you're using a genuine Chrome stack behind the scenes, your TLS handshake (JA3/JA4) looks like a normal browser, not a Python script or custom TLS client.

Browser fingerprint

CDP gives Browserless the ability to set launch flags and extensions so your WebGL renderer, fonts, and other device attributes match a real machine fingerprint more closely than a stock headless instance.

Statefulness

Instead of spinning up a new blank profile each time, you can use Browserless reconnects and user data directories to keep the same device configuration across sessions, which is what real users do.

For more aggressive anti-bot setups (Cloudflare, etc.), you can combine this with:

  • playwright-extra plus stealth plugins to hide automation markers like navigator.webdriver and headless-only values.
  • Browserless /unblock flows, which return a CAPTCHA-approved session and cookies pre-tuned to pass strict bot detectors, so your Playwright code can attach to an already "trusted" browser.

This setup lets you focus on application logic instead of deep JS and TLS fingerprint juggling.

Bypass fingerprint detection in Puppeteer – with Browserless

With Puppeteer, the pattern is similar, but you use puppeteer-core and connect:

On top of that, Browserless gives you features specifically aimed at replicating the behavior of a real user and bypassing bot detection:

  • Reconnects – keep a logged-in browser running on the server and reconnect by WebSocket later, preserving cookies, localStorage, and sessionStorage, just like a real user's device.
  • /unblock endpoint – launch a remote browser session that automatically handles bot detection, proxy configuration, and CAPTCHA solving, returning a browserWSEndpoint and cookies you can re-use in Puppeteer.
  • User data directories – reusing --user-data-dir across runs preserves device configuration, installed plugins, and user's preferences over time, which improves the consistency of the unique fingerprint.
  • **Stealth route **– combine BrowserQL's automation features with comprehensive browser fingerprint mitigations and entropy injection to bypass bot detection.

If you want even more control over browser fingerprinting techniques at the JS level in Puppeteer:

  • Libraries like fingerprint-suite (with fingerprint-injector) can inject realistic browser fingerprints into an automated browser instance.
  • Puppeteer-extra's stealth plugin can hide obvious automation markers.

Use these carefully: inconsistent combinations (for example, "Linux UA + Windows fonts + mobile screen resolution") can be worse than defaults.

How to bypass TLS Fingerprinting

Here is a quick step-by-step guide to bypassing TLS Fingerprinting:

  1. Use real browsers like Playwright or Puppeteer so your TLS handshake matches Chrome or Firefox.
  2. If you need raw HTTP, use clients that impersonate browser TLS stacks (for example, curl-impersonate, utls) instead of default Python requests.
  3. Keep TLS, HTTP headers, and JavaScript capabilities consistent – don't claim to be Chrome in headers while your TLS and JS look like something else.
  4. Rotate realistic browser versions and operating systems, not random or outdated configs.
  5. Respect legal and ToS boundaries; bypassing TLS-based bot checks on third-party sites can carry real risk.

Browserless helps here because it always puts a genuine browser in front of your code – you connect over CDP and never have to hand-craft TLS behavior yourself.

Other ways to bypass fingerprint detection

Beyond Playwright and Puppeteer tuning, there are other levers you can pull – some for automation, some for personal privacy.

1. Use privacy-focused browsers (for manual use)

For your own browsing, not automation:

  • Browsers like Brave and Firefox include anti-fingerprinting protections: they standardize screen resolution, limit system fonts, and randomize certain attributes to make users look more similar and reduce unique attributes.
  • Tor Browser goes further by disabling many APIs and encouraging you to look exactly like other Tor users (but it's slow and breaks sites).

This is useful when you care about online tracking more than usability. It's not meant as a tool for data scraping.

2. Reduce information collected (for your own sites)

If you're on the defensive side, trying to protect your users:

  • Avoid loading third-party scripts that aggressively fingerprint users unless they're truly needed for preventing fraud.
  • Use Content Security Policy to limit which domains can run fingerprinting JavaScript.
  • Be explicit in your privacy policy about what fingerprinting techniques you use and why.

You can still use device fingerprinting to prevent fraud and accurately determine risky behavior, but you should do it transparently and with legal review.

3. Environment and VM hygiene for automation

If you're running scrapers across multiple devices or virtual machines, make sure:

  • Each VM or container has a plausible device configuration – CPU count, memory, OS, graphics – that matches your declared user agent and device attributes.
  • You don't accidentally run hundreds of "identical" environments with the same digital fingerprint, especially when combined with the same proxy IP ranges.
  • You keep browser plugins and installed fonts consistent within a persona, so the unique fingerprint doesn't jitter unnaturally across sessions on the same device.

Browserless effectively gives you this per-session environment out of the box, so you don't have to hand-tune virtual machines or manage a fleet of different devices.

4. JS-level fingerprint shaping (use cautiously)

For legitimate scraping of sites you're allowed to access, you can:

  • Use libraries like fingerprint-suite to inject realistic browser fingerprints into Playwright/Puppeteer sessions.
  • Use stealth plugins to harmonize navigator properties, fix navigator.webdriver, and align WebGL or canvas outputs.

A minimal Playwright + fingerprint-injector example (DIY path, not Browserless-specific):

This is powerful, but it's easy to create inconsistent combos (e.g., Windows UA, but Linux TLS fingerprint because your underlying machine is Linux), which increase suspicion. Anti-bot platforms are increasingly using machine learning over multiple layers – browser, device, TLS, and behavioral – not just a static list of fingerprinting techniques.

When that happens, Browserless's approach of aligning everything at the CDP and infrastructure level tends to age better than hand-tuned JS patches.

Conclusion

Fingerprinting is no longer a niche trick, it's a core part of how modern websites identify users, protect accounts, and fight fraud.

As a developer working with Playwright or Puppeteer, that means default headless settings will get you flagged: telltale user agents, obvious automation markers, and unrealistic device data make your browser fingerprint stand out.

TLS fingerprinting can block you before your HTTP request hits application code, so just spoofing headers isn't enough. Behavioral fingerprinting and machine learning models, meanwhile, increasingly look at how your automation behaves over time, not just what device attributes it claims to have.

The sustainable way forward is to:

  • Use real browsers for automation, so your TLS and browser fingerprints look like genuine users.
  • Make your device configuration, browser type, operating system, and user's preferences internally consistent – one realistic device, not a Frankenstein of random settings.
  • Respect legal and ethical limits, especially when accessing third-party websites.
  • Lean on managed infrastructure like Browserless when you're tired of babysitting proxies, sessions, and low-level fingerprint tricks – it's effectively the same sort of stack you'd build yourself, just maintained and battle-tested for you.

You won't be invisible, but you'll be a lot less obvious – and your automation will behave much more like a real user on a real device.

FAQ

What is browser fingerprinting? Browser fingerprinting collects attributes from your browser—User-Agent, screen resolution, installed fonts, WebGL renderer, and canvas output—to create a unique identifier. Unlike cookies, nothing is stored on your device, so clearing cookies or using incognito mode won't reset your fingerprint.

What's the difference between browser fingerprinting and device fingerprinting? Browser fingerprinting focuses on attributes exposed by a single browser (JavaScript APIs, HTTP headers). Device fingerprinting zooms out to combine browser data with hardware configuration, operating system, IP address, and cross-device signals to identify the same device across multiple browsers and apps.

How does TLS fingerprinting work? TLS fingerprinting analyzes the encrypted connection handshake before any HTTP or JavaScript runs. The ClientHello message reveals supported TLS versions, cipher suites, and extensions—creating a JA3 or JA4 hash that can identify whether your client is a real browser or a bot.

Can you bypass fingerprint detection in Playwright or Puppeteer? Yes. Use real browsers via CDP to inherit realistic TLS fingerprints, configure consistent browser contexts (user agent, viewport, locale, timezone), and maintain sessions to appear like a returning user. Managed platforms like Browserless handle low-level fingerprint tuning automatically.

Is bypassing fingerprint detection legal? It depends on context. Bypassing fingerprinting to test your own systems, run authorized QA automation, or access data within site terms is generally acceptable. Bypassing technical protections on third-party sites may violate their terms of service and, in some jurisdictions, computer misuse laws.

What's the best way to avoid TLS fingerprinting blocks? Use real browsers (Playwright or Puppeteer with genuine Chrome) so your TLS handshake matches a normal browser. If you need raw HTTP, use TLS-impersonating clients like curl-impersonate or utls. Keep TLS, HTTP headers, and JavaScript capabilities consistent—don't claim Chrome in headers while your TLS looks like Python requests.