What is browser fingerprinting?

TL;DR

Browser fingerprinting builds an identifier out of the properties a browser exposes to any page it loads: installed fonts, screen dimensions, timezone, language, graphics hardware, audio processing, and dozens more. No single value is unique, but the combination usually is, and it survives cleared cookies and private windows. Anti-bot systems use it to recognise automated traffic, because headless browsers produce combinations that real machines rarely produce.

What gets measured

A page can read far more than most people expect, all through ordinary JavaScript APIs:

• Screen and window. Resolution, colour depth, available screen area, device pixel ratio.
• Locale. Timezone, language list, date and number formatting.
• Hardware. CPU core count, device memory, touch support.
• Fonts. Which fonts are installed, detected by measuring rendered text width.
• Canvas. The same drawing instructions produce subtly different pixels on different GPU and driver combinations.
• WebGL. Renderer and vendor strings, plus rendering differences.
• Audio. An oscillator processed through the audio stack yields slightly different output per machine.

Canvas and WebGL are the strongest signals, because they reflect the actual graphics stack rather than something the browser reports about itself.

Why automated browsers stand out

Detection mostly comes down to spotting combinations of values that do not occur naturally, rather than finding any single "bot" flag.

A default headless Chrome on a Linux server reports no touch support, a small set of fonts, a software renderer such as SwiftShader instead of a real GPU, and often a screen size of exactly 800 by 600. Each value is plausible alone. Together they describe a machine almost nobody browses on. Add a datacenter IP and the picture is unambiguous.

Inconsistency is the other giveaway. A user agent claiming macOS paired with Linux font metrics, or a timezone of Europe/Madrid arriving from an IP in Ohio, is a stronger signal than any single odd value, because real browsers are internally consistent by default.

Why spoofing individual values usually fails

The common first attempt is overriding the user agent, then patching navigator.webdriver, then adding fake plugins. This tends to make things worse. Each override has to stay consistent with every other value, and modern detection scripts check dozens of relationships between them. A property that has been redefined in JavaScript can often be detected as redefined, which is itself a signal no real browser produces.

Where Zenrows fits

Fingerprint consistency is what Adaptive Stealth Mode handles in Zenrows Fetch. Rather than exposing individual knobs to tune, it selects a coherent configuration for the target site, so the fingerprint, headers and IP describe the same plausible machine instead of three different ones. That consistency is the part that is difficult to maintain by hand as detection scripts change.

Key takeaways

Fingerprinting identifies visitors by combining many browser-exposed properties into a signature that does not depend on cookies. Canvas, WebGL and font measurements carry the most weight. Automated browsers are caught less by any single flag than by improbable combinations and internal inconsistency, which is why patching values one at a time tends to increase exposure rather than reduce it.