Browser stealth explained: WebGL and GPU fingerprinting
A website can compare the GPU a browser claims to use with how it actually draws. Changing the reported name leaves other clues.
WebGL is how websites draw maps, games, and 3D scenes through the browser's graphics system. A page can also use it to read the resulting pixels and ask which graphics features are available.
Those answers help describe the browser's environment. A site can compare them across visits or check whether they fit the graphics hardware the browser claims to use. DataDome lists GPU information and consistency challenges as inputs to Device Check.
For a stealth browser, changing the reported GPU name leaves a problem: the page can still test how it draws.
How a drawing becomes a fingerprint
A fingerprinting script gives browsers the same drawing task and compares their results. The graphics hardware and software both affect the output, so tiny pixel differences can reveal something about the system that produced them.
The page can read those pixels and turn them into a hash, a short signature it can compare later. The Pixel Perfect research explored comparing rendering results against known browser configurations.
A page can also collect supported features and limits, such as the largest texture the browser accepts. FingerprintJS's WebGL collector gathers this kind of information. A 2026 study observed WebGL measurements in HUMAN Security scripts too.
Many browsers can share a signature, and a browser or driver update can change it. Combining the drawing with other measurements helps narrow the possible configurations.
Checking the claimed GPU against its behavior
A detector can run a drawing task on known configurations and store their results. It then compares a new browser's pixels and capabilities with that reference database.
Suppose a browser reports an NVIDIA RTX 3060, but its results match a known SwiftShader configuration. SwiftShader draws in software. Changing its reported name has left other clues about the system doing the work.
The database needs more than GPU names: browser versions and drivers can affect the output too. Several configurations may match, while a new configuration may have no record yet. Software rendering is also used by legitimate browsers, so it needs context when assessing a visitor.
A simpler consistency check needs no database. Reading the same unchanged pixels twice should return the same values. Reading a small section should also agree with that section inside a larger capture, under the same WebGL settings. Random changes applied differently to each read can break that agreement.
What defenses change, and what they cost
Each approach affects a different part of what the page can observe.
| Approach | Main limitation |
|---|---|
| Change the GPU name | Drawing results and capabilities remain measurable. |
| Hide detailed GPU information | Ordinary graphics queries and drawings still work. |
| Add noise to returned pixels | Different reads must agree, and image-processing tools may need exact values. |
| Disable WebGL | Maps and 3D viewers can break without a fallback. |
Firefox's Resist Fingerprinting can hide detailed renderer information. WebKit has described adding noise to returned pixels while leaving the visible drawing unchanged.
Neither removes every way to measure graphics behavior. The DrawnApart study, for example, explored differences in how long GPU tasks take. Protecting pixel values still leaves those timing measurements to consider.
How Notte handles graphics
Our Chromium patches coordinate the reported renderer name with selected capability limits and available features. They cover both WebGL and the newer WebGPU interface.
We make these changes inside the browser engine so related queries can use the same profile. The actual graphics backend still draws the image, so we also need to check its output against what the browser reports.
Notte sessions provide this browser setup alongside canvas and audio protections. A consistent graphics profile is one part of the session a bot detector sees.