apify/fingerprint-suite: generating and injecting browser fingerprints for Playwright and Puppeteer

The problem fingerprint-suite solves, and who it is actually for

Sites that fingerprint visitors do not need a login to recognise a scraper. They read the combination of HTTP headers, JavaScript API values and rendering quirks that a browser exposes, and a stock headless Chromium returns a combination no real visitor produces. The README frames the project's purpose in exactly those terms: "Today's websites are increasingly using fingerprinting to track users and identify them." The suite exists so that a scraper presents a coherent fingerprint instead of an obviously synthetic one.

The audience is narrow. You need to be running a browser you control through Playwright or Puppeteer, and you need to care about the header and JS-API surface rather than just IP reputation. Teams scraping public catalogues at low volume will not get much from this. Teams running large browser fleets against sites with bot detection will, because the alternative is maintaining a hand-tuned browser patch.

The suite is modular rather than a single library. The README lists four npm packages: header-generator for HTTP headers, fingerprint-generator for full browser fingerprints, fingerprint-injector for pushing a fingerprint into a running browser, and generative-bayesian-network, described as "our fast implementation of a Bayesian generative network used to generate realistic browser fingerprints." You can take one or all of them.

How generation and injection are separated in the architecture

The design splits into two halves that meet at a data structure. The generator half produces a fingerprint object from a model. The repository layout shows where the model lives: packages/fingerprint-generator/src/data_files/fingerprint-network-definition.zip, a file that the Python packaging config also copies into the apify_fingerprint_datapoints wheel. That zip is the trained network the Bayesian package samples from, and it is the reason the generator can produce values that co-vary the way real browser configurations do, rather than independent random numbers.

The injector half takes that object and applies it. newInjectedContext and newInjectedPage wrap the browser's own context or page creation, so the fingerprint is installed before your code navigates anywhere. Header generation is a separate concern: header-generator produces the request headers, which is why the README describes fingerprint-generator as affecting "the HTTP headers and browser JS APIs" while header-generator only produces headers.

The practical consequence is that generation is offline and cheap. You can generate a batch of fingerprints, store them, and inject them later, which is how you would keep a stable identity across sessions. The README does not document a persistence or rotation API for that workflow, so you would be storing the generated objects yourself.

There is also a Python side to the repository. pyproject.toml defines a package named apify_fingerprint_datapoints, version 0.15.0, described as "Browser fingerprint datapoints collected by Apify". It requires Python 3.8 or newer and force-includes the same network definition zip plus a browser helper file. That is a data distribution, not an injector.

Installing fingerprint-injector and injecting your first context

The packages are published separately on npm, so you install the injector and Playwright or Puppeteer as your own dependencies. The README's quick start imports from 'playwright' and from 'fingerprint-injector', which means the injector package is the one you add. The repository is a pnpm workspace with turbo scripts, but that layout is for contributors building from source, not for consumers.

npm install fingerprint-injector playwright

The Playwright example from the README launches Chromium, then calls newInjectedContext with a fingerprintOptions object. Here devices and operatingSystems constrain the generated fingerprint to a mobile iOS device, and newContextOptions is passed through to Playwright's own newContext().

import { chromium } from 'playwright';
import { newInjectedContext } from 'fingerprint-injector';

const browser = await chromium.launch({ headless: false });
const context = await newInjectedContext(browser, {
    fingerprintOptions: {
        devices: ['mobile'],
        operatingSystems: ['ios'],
    },
    newContextOptions: {
        geolocation: { latitude: 51.50853, longitude: -0.12574 },
    },
});

What you should see is a context whose pages report iOS mobile characteristics rather than the host machine's. The Puppeteer path is symmetrical but returns a page directly, via newInjectedPage, and the README's example navigates to https://example.com afterwards.

import puppeteer from 'puppeteer';
import { newInjectedPage } from 'fingerprint-injector';

const browser = await puppeteer.launch({ headless: false });
const page = await newInjectedPage(browser, {
    fingerprintOptions: {
        devices: ['mobile'],
        operatingSystems: ['ios'],
    },
});

Note the headless: false in both examples. The README does not present a headless variant in the quick start, and the README does not document which fingerprint fields are safe to override by hand, so treat fingerprintOptions as the supported surface.

Where fingerprint-suite is the wrong tool

The suite operates at the browser API and header layer. It does not change your IP address, your TLS handshake, or your request timing. A site that fingerprints at the network layer will still see whatever your proxy or datacentre egress looks like, and no amount of consistent navigator.platform will fix that. If your blocking is IP-based, this project addresses the wrong layer.

The second boundary is maintenance of the underlying data. The fingerprint network is a bundled artefact, regenerated through scripts the repository exposes as buildNetwork and verifyModel. Browser versions move, and a fingerprint that was coherent for one Chromium release can become internally inconsistent for the next. The README does not state a compatibility matrix between package versions and browser versions, so you are responsible for testing against the browsers you actually launch.

Third, this is not a stealth browser. It does not patch Chromium, and it does not claim to defeat any specific detection vendor. The repository contains a benchmark script at test/antibot-services/live-testing/cloudflare.ts, which indicates the maintainers measure against at least one anti-bot service, but the README publishes no results from it. Anyone expecting a documented pass rate will not find one here.

Finally, the Python package is a trap for the unwary. apify_fingerprint_datapoints ships fingerprint data, not injection logic. If your stack is Python and you want injection, this repository does not give you a Python equivalent of newInjectedContext.

How it differs from patched-browser and stealth-plugin approaches

The closest alternative category is a patched browser distribution paired with a stealth plugin, where the browser binary itself is modified and a plugin suppresses the obvious automation tells. That approach bundles everything: you install one browser and one plugin, and you get a fixed set of evasions maintained by whoever ships the patch.

fingerprint-suite takes the opposite position. Nothing is patched; the fingerprint is generated as data and injected at context creation. The README's own framing is that the packages "you can use separately, or together", and the network definition is a data file rather than a fork of Chromium. The trade-off is explicit. You get composability and the ability to generate thousands of distinct coherent identities offline, and you give up the deep binary-level patching that a stealth browser build can do.

A second difference is the generation model. Randomising individual properties independently produces combinations that never occur in the wild, which is itself a signal. The generative-bayesian-network package exists to avoid that, sampling from a learned distribution instead. A stealth plugin typically hardcodes a small set of overrides, which is simpler to reason about and easier to detect once it is known.

If your requirement is a single browser that passes a specific check out of the box, a patched build is less work. If your requirement is many distinct, plausible identities inside a browser you already control, the generator-and-injector split is the more direct fit.

Versioning, licence and what upgrading costs

The repository is a monorepo with a single root version, currently 2.1.88 in package.json, and the recent release tags track it closely: v2.1.88 on 2026-08-05, v2.1.87 on 2026-08-01, v2.1.86 on 2026-07-24. The last push to the default branch was on 2026-09-21, so the codebase is being touched, though the release cadence is what matters for consumers. Patch-level releases at that frequency mean upgrades are routine and low-drama, but they also mean the fingerprint data is refreshed often enough that pinning an old version for a long time will leave you with stale browser characteristics.

The Python side versions independently. pyproject.toml declares apify_fingerprint_datapoints at 0.15.0 with a separate changelog, so a Python consumer and an npm consumer of the same repository can be on unrelated version numbers.

Licensing is Apache-2.0 at the root, per package.json and LICENSE.md. The pyproject.toml carries the Apache Software License classifier as well. The one thing worth checking yourself is the provenance of the bundled data: the wheel force-includes fingerprint-network-definition.zip and a browser helper file from the TypeScript packages, and the README says nothing about the terms attached to that collected data. Read LICENSE.md and the datapoints README before shipping it in a commercial product. That is a question for your own legal review, not something this article can settle.

Editorial conclusion

Adopt apify/fingerprint-suite if your scraping stack already runs Playwright or Puppeteer and you want fingerprint generation and injection as separate npm packages rather than a patched browser build. Do not adopt it if you need a drop-in stealth browser or a Python client for the injection step; the repository ships a Python package only for the datapoints, and the injector is TypeScript. Before committing, check that the fingerprint options you need (devices, operatingSystems) are accepted by your installed version, and read LICENSE.md rather than assuming Apache-2.0 covers the bundled data files.

Frequently asked questions

Official sources

1. apify/fingerprint-suite on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases