How to Detect Bots on Your Website Using Browser Fingerprinting

Most website owners think bot detection means blocking suspicious IP addresses. It doesn't. Modern bots rotate IPs, use residential proxies, and mimic real user behavior well enough to fool basic detection systems. The signals that actually reveal automated traffic come from the browser itself — and most bots can't fake them convincingly.

GPU_RENDERER...

SCREEN_RESOLUTION...

PIXEL_RATIO...

↑ These three signals alone reveal whether this browser session is likely human or automated.

Why IP Blocking Isn't Enough

IP addresses are the first line of defense — and the first thing sophisticated bots work around. Residential proxy networks give bots IP addresses that look like real home connections, from real ISPs, in real cities. Blocking by IP or ASN catches only the unsophisticated bots running directly from datacenter servers.

The bots that actually cost you money — the ones scraping your prices, stuffing credentials, creating fake accounts, or inflating your ad metrics — are running through residential proxies and look perfectly clean from a network perspective.

Browser fingerprinting works at a different layer. Instead of asking "where is this connection coming from?" it asks "does this browser behave like a real human browser?" The answers are very different.

What Browser Fingerprinting Reveals About Bots

Headless browsers — the tools most bots use to simulate a real browser — leave a distinct set of signals that differ from genuine user sessions. Not because they're trying to look like bots, but because they run in environments that lack the hardware and software of a real user's device.

GPU Renderer

The single most reliable bot signal. Real browsers render graphics using the device's actual GPU — NVIDIA, AMD, Intel, or Apple Silicon. Headless browsers running on servers use software renderers like SwiftShader, llvmpipe, or Mesa. These names appear directly in the WebGL renderer string, readable by any JavaScript on the page.

GPU_RENDERER...

A real user's GPU renderer string looks like ANGLE (NVIDIA, NVIDIA GeForce RTX 3080...). A headless browser's looks like ANGLE (Google, Swiftshader...).

The difference is immediate and reliable.

Screen Resolution & Pixel Ratio

Headless browsers default to specific resolutions that differ from real user devices. 800×600, 1024×768, and 1280×720 are common headless defaults that rarely appear in genuine user traffic. Combined with a pixel ratio of exactly 1.0 — which real high-DPI devices (phones, Retina displays, modern laptops) never report — these signals together strongly suggest an automated session.

SCREEN_RESOLUTION...

PIXEL_RATIO...

Language & Timezone Consistency

Real browsers have language preferences set by the user. Headless browsers often have no language preference at all, or report a default that doesn't match the IP address's geographic location. A browser claiming to be in New York but with no language preference set, or with a timezone inconsistent with the IP's location, is a strong automated traffic signal.

LANGUAGE...

Cookie & Storage Behavior

Some bots run with cookies disabled entirely. Others accept cookies but don't persist them between sessions the way real browsers do. Checking whether cookies are enabled — and whether they were set on a previous visit — adds another layer to the detection profile.

COOKIES...

Device Memory & CPU Cores

Servers running headless browsers often expose unusual hardware configurations. A single CPU core, or an implausibly high core count, combined with unavailable device memory readings, suggests a virtualized or containerized environment rather than a real user's device.

The Bot Score: Combining Signals

No single signal is definitive. A real user might have an unusual screen resolution. A sophisticated bot might spoof a realistic GPU string. The power of browser fingerprinting for bot detection comes from combining signals into a probability score.

A simple scoring approach:

A score above 60 indicates likely automated traffic. Below 30 is almost certainly a real user. The middle range — 30 to 60 — warrants additional checks or rate limiting rather than an outright block.

{
  "bot_score": {
    "score": 40,
    "verdict": "suspicious",
    "flags": [
      "headless default resolution",
      "no language preference",
      "cookies disabled"
    ]
  }
}

What to Do With Bot Detection

Detecting a bot is only half the problem — deciding what to do with that information is the other half. A hard block on anything above a threshold will catch some real users in the net. A more nuanced approach scales the response to the score.

Below 30, serve the visitor normally and take no action at all. The overwhelming majority of real traffic lands here, and anything you do to this group is friction applied to genuine users.

Between 30 and 60, add friction rather than a wall: rate limit the session, present a CAPTCHA on sensitive actions, or flag the session for manual review. This band contains both cautious real users and moderately capable bots, so the response should be recoverable for a human.

Above 60, block the action rather than the IP address, require additional verification, or silently return empty results to avoid tipping off scrapers about what triggered the detection. Blocking the action leaves a misidentified human a path forward; blocking the IP does not.

One rule is worth holding to regardless of score: never block access to public content on bot score alone. Restrict specific actions — form submissions, API calls, account creation, checkout — and leave the reading of public pages open.

Implementing Bot Detection

There are two approaches, depending on your stack.

Client-side (easiest)

Add a JavaScript snippet that collects browser signals and sends a bot_score to your backend with each form submission or sensitive action. Your backend decides what to do based on the score.

Server-side via API (more reliable)

Use a browser intelligence API that returns bot_score alongside IP, location, and device signals on every request. This runs before any client-side JavaScript executes, making it harder to spoof.

See Your Own Bot Score

You can check what bot score your own browser gets right now — and see all 21 signals the MySysInfo API returns.