· 10 min read · Lobster Browser team
A browser fingerprint is what a website can work out about your device without storing anything on it. No cookie, no login, no local storage — just the answers your browser gives to questions any page is allowed to ask, combined into something distinctive enough to recognize you again.
This post explains the mechanism rather than the politics: what a fingerprint is, the surfaces it is assembled from, the two properties — entropy and stability — that decide whether it is useful to a collector, the coherence idea most discussions skip, why a badly built disguise is more identifying than none, and what sites do with the result.
Every browser exposes a great deal of configuration to the pages it loads, for good reasons: a page needs the viewport size to lay itself out, the language to choose a translation, the time zone to render a timestamp, the available fonts to pick a fallback. Each answer is individually unremarkable and shared with many other people.
A fingerprint is the combination. Collect enough weakly distinctive answers and the intersection becomes narrow. This is the same arithmetic as a guessing game: no single question identifies you, but twenty of them can. In fingerprinting research the measure is entropy — how much the answer to a question narrows down the population — and the total is roughly the sum across independent surfaces.
Two clarifications matter. A fingerprint is not an identifier the browser hands out; it is computed by the collector from many observations, so two collectors can compute different fingerprints from one visit. And it is not necessarily unique: a common phone with default settings is hard to distinguish from millions of others, while an unusual desktop with a rare font set is often unique on the first visit.
These are the signals that appear in almost every commercial fingerprinting script. The list has been stable for years; what changes is the weighting.
The classic User-Agent header declares browser, version and platform as a long string full of legacy fragments. It is being narrowed deliberately: browsers freeze parts of it and move the detail into User-Agent Client Hints, where a site gets a small set by default and must ask for high-entropy parts such as full version, architecture and model. That reduces passive collection without removing the information — it makes the request visible.
Screen dimensions, available area after system chrome, color depth and the ratio between CSS pixels and device pixels. Stable for a desktop, and more distinctive than people expect once the available area — which encodes taskbar position and size — is included.
A script draws text and shapes to an off-screen canvas and reads the pixels back. The result depends on the font rasterizer, anti-aliasing, the graphics stack and the platform's text shaping, so two machines with different hardware or fonts produce different pixels for the same instructions. Canvas is one of the highest-entropy surfaces available and is cheap to collect.
The graphics API exposes vendor and renderer strings — effectively the GPU and driver — with dozens of capability limits and supported extensions. Rendering a scene and hashing the result adds another layer, since floating-point behavior differs between drivers. A strong hardware signal, and a difficult one to alter convincingly.
An oscillator is rendered through a processing graph offline and the samples are hashed. Differences in the audio stack and floating-point implementation produce small, consistent differences per device class: lower entropy than canvas, but very stable and almost never noticed.
The installed font set is a strong signal because it reflects the operating system, the language packs and every application ever installed that shipped a typeface. Even where enumeration is restricted, a script can measure the rendered width of a string in a candidate font against a fallback and infer presence from the difference.
The reported time zone, the preferred languages, and the formatting conventions the internationalization APIs produce for dates, numbers and currencies. Individually low entropy; collectively meaningful, and — as the next section explains — unusually good at catching inconsistency.
Logical processor count, an approximate memory figure, maximum touch points and the platform string. Coarse by design, and useful mainly as a cross-check.
The real-time communication stack can reveal local network addresses during connection setup, and historically exposed a true public address even behind a proxy. Browsers have tightened this, but it remains the classic way a network identity and a browser identity end up disagreeing.
| Surface | Entropy | Stability | Notes |
|---|---|---|---|
| Canvas rendering | High | High | Depends on fonts, rasterizer and graphics stack |
| WebGL vendor, renderer and limits | High | High | Effectively identifies the GPU and driver |
| Installed fonts | High | Medium | Changes when software is installed |
| User-Agent and client hints | Medium | Medium | Changes on every browser update |
| Screen and available area | Medium | High | Encodes system chrome as well as the panel |
| Audio processing | Medium | High | Quiet, consistent, rarely noticed |
| Time zone and locale | Low | High | Weak alone; excellent as a consistency check |
| Hardware counts | Low | High | Coarse; mainly used for cross-checking |
| WebRTC addresses | Variable | Low | Situational; the classic network-identity leak |
A surface is useful when it is both distinctive and persistent, and the two trade off: window size is distinctive at a moment and changes constantly, while the graphics renderer string lasts for the life of the machine and is shared with everyone who owns the same hardware.
This is why serious collectors do not compute one hash. They keep the components separately and match probabilistically: a visitor whose canvas, audio, fonts and graphics signature are unchanged but whose browser version moved by one is obviously the same device after an update. Treating a fingerprint as one opaque value hides how matching works — and it is why changing a single surface rarely accomplishes anything.
A real device is internally consistent, because all of its answers come from the same machine. That consistency is a rich source of verification, and it is what most detection actually tests. Some examples, all of them routinely checked:
None of these requires knowing who you are — only what a real device of the claimed kind looks like, and that knowledge is abundant because real devices visit constantly. A collector with a large sample needs no rule for every combination: an unseen or self-contradictory one is itself the signal.
The intuition that changing a value hides you is backwards in this domain, for a reason worth internalizing: the goal of blending in and the goal of hiding a value are in direct conflict.
Consider an extension that replaces the User-Agent. The header now says something plausible, but the JavaScript environment still exposes the original browser's features, the canvas still rasterizes as it did, and the accessor returning the User-Agent is no longer the native function it should be. The visitor has not become someone else; they have become an unusual visitor whose story does not hold together — and an inconsistency is rarer, and so more identifying, than the honest configuration was.
A second failure is subtler. Randomizing a surface on every page load defeats long-term tracking and creates a new signal: real devices do not produce a different canvas hash every minute. Unbounded randomization is itself detectable, which is why the tools that do it well key their noise per site and per session rather than per call.
Fingerprinting is not one activity with one motive. Four uses dominate.
| Use | What it wants | How it behaves |
|---|---|---|
| Fraud prevention | Is this the device that usually signs in to this account? | Heavy collection; probabilistic matching; a mismatch triggers a challenge rather than a block |
| Bot detection | Is this an automated client pretending to be a person? | Looks for automation tells and incoherence more than for identity |
| Rate limiting and abuse control | Are these hundred accounts one device? | Coarse clustering; tolerant of false positives |
| Advertising and analytics | Can this visit be linked to previous ones without a cookie? | Increasingly constrained by browser policy and regulation |
The first three are why fingerprinting persists even as third-party cookies decline: they are security functions, and a site that abandons them accepts fraud. That explains an asymmetry many people notice — an unusual but coherent visitor is often let through with a challenge, while an incoherent one is treated as automation immediately.
All four are compromises. Uniformity is the strongest and most restrictive; noise is comfortable and, if implemented carelessly, detectable; reduction is quietly the most effective in aggregate, because it lowers the entropy available to every collector at once.
A fingerprint is a combination, not a value: many weak answers intersected into something narrow. The strong surfaces are canvas, graphics, fonts and the hardware behind them; the weak ones — time zone, locale, processor count — earn their place by catching contradictions rather than by identifying anyone. Collectors match probabilistically on components, so changing one surface changes almost nothing. And because real devices are internally consistent, incoherence is the loudest signal a visitor can emit. The question is never “have I changed this value”; it is “does everything I expose still describe one plausible machine”.
Named rather than linked, on purpose: specifications move and URLs rot, while a title and an author survive a search.
· 10 min read
How anti-detect browsers work: JavaScript overlays versus native engine changes, farbling, per-profile stability, and how to evaluate one honestly.
· 10 min read
Perception, action spaces, settling, verification and safety boundaries — how an agent operates a browser, and why a real browser beats a headless scraper.
· 10 min read
A framework for model selection: capability axes, what benchmarks can and cannot show, latency and cost, reasoning modes, and open-weight versus hosted.
· 9 min read
What separates an agent from a chatbot: tool use, the planning loop, memory, evaluation and guardrails — and the places agents still reliably fail.
