TL;DR: A browser fingerprint is the set of signals a website reads from your browser, such as user agent, screen size, installed fonts, and how your graphics card renders an image, that together identify one browser among millions. Sites use it to tell a real user from an automated one, which is why AI agents driving a browser tend to get flagged. The fix is not to hide the agent but to give it a real fingerprint that bot protection recognizes.

You build an agent that logs into a dashboard, fills a form, and pulls a report. It works on your laptop every time. You deploy it, and now the site throws a challenge page or quietly serves it different content. Nothing in your code changed. What changed is the fingerprint the site read, and it no longer looks like a person sitting at a real browser.

What is a browser fingerprint?

A browser fingerprint is a profile a website builds from the signals your browser exposes as it loads a page. No single signal identifies you. Taken together, dozens of them form a combination distinctive enough to recognize the same browser across visits, often without a cookie.

The signals fall into a few groups:

• HTTP and JavaScript attributes. User agent, language, timezone, screen resolution, color depth, and the list of installed fonts and plugins.
• Rendering signals. Canvas and WebGL draw the same shape or text slightly differently depending on your GPU, drivers, and OS, producing a stable value a site can hash.
• Hardware and environment. CPU core count, device memory, audio stack behavior, and touch support.
• Behavioral signals. Mouse movement, scroll timing, and keystroke cadence, which separate a human from a script even when the static signals look normal.

Because the combination is stable and hard to change, a fingerprint works as a persistent identifier. That is the point for the site reading it.

How does browser fingerprinting work?

When a page loads, scripts on the site collect the signals above and combine them into a hash, a short string that stands for that specific browser configuration. The site stores the hash and compares it on the next visit. If two requests share a fingerprint, they are almost certainly the same browser, even from a new IP address and with cookies cleared.

Bot protection services take this further. They score how plausible the fingerprint is, not just whether it is unique. A configuration that never occurs on real consumer hardware, a headless Chrome flag left on, a GPU string that does not match the reported OS, a font list too clean to be a real machine, reads as automated and gets challenged or blocked.

Why does fingerprinting matter for AI agents?

AI agents run in the cloud, often in headless or containerized browsers that leave tell-tale marks. A default automation setup tends to produce a fingerprint that is either too generic, identical across thousands of runs, or internally inconsistent, an OS and GPU that never ship together. Both patterns look nothing like a person on a laptop, so the agent gets flagged even when it is doing legitimate work a human could do by hand.

This is why an agent passes locally and fails in production. On your machine it inherits a real browser fingerprint. In the cloud it inherits the fingerprint of a data center browser, and that is exactly the profile bot protection is tuned to catch.

How do AI agents get verified access despite fingerprinting?

The durable answer is not to hide the agent. It is to give the agent a real, consistent browser identity that bot protection recognizes as legitimate. Browserbase does this with Verified, a purpose-built Chromium browser that runs with real browser fingerprints rather than randomly generated ones, so sessions are recognized as legitimate participants instead of anomalies.

Enabling it is one browser setting on the session, paired with proxies for the best results:

import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });

const session = await bb.sessions.create({
  browserSettings: {
    verified: true,
  },
  proxies: true,
});
console.log(session);

You can match the fingerprint to a target environment by setting an OS, which changes the user agent and environment signals to a complete, pre-made profile instead of a mismatched one:

const session = await bb.sessions.create({
  browserSettings: {
    verified: true,
    os: "mac",
  },
  proxies: true,
});

The profiles are crafted to work as a whole, so the reliable pattern is to enable Verified and leave the viewport and user agent alone rather than overriding individual signals through your automation framework, which is how mismatches creep back in.

Fingerprinting vs cookies: what is the difference?

The short version is that a cookie is a file the site sets and you can delete, while a fingerprint is reconstructed from your browser configuration and cannot simply be cleared. A site can recognize a fingerprint even after you clear cookies and change your IP. The table below breaks down the differences.

Last updated: August 2026. Ready to give your agent a real browser identity? See the Agent Identity overview to enable Verified access.