WebGPU Fingerprinting: The Next Generation of GPU Tracking

WebGPU exposes adapter info, feature names, capability limits and rendering output that a page can compare, and they should agree with what WebGL reports. BotBrowser offers profile, real and disabled modes through --bot-webgpu for controlled tests, but it does not guarantee that WebGPU is available, add features the host cannot expose, or identify physical hardware.

TL;DR

Set --bot-webgpu=profile together with --bot-webgl=profile, add --bot-noise-seed for deterministic rendering, and check adapter info, features, limits, WebGL-WebGPU vendor agreement and cross-session stability. Choose disabled only when the application does not need WebGPU.

Contents

• Watch the video
• Introduction
• Privacy Impact
• Why This Matters for Your Privacy
• Common Protection Approaches and Their Limitations
• BotBrowser's Profile-Managed Approach
• Configuration and Usage
• Verification

BotBrowser documents selectable WebGPU modes for controlled tests; it does not guarantee WebGPU availability, hide every adapter signal, or identify physical hardware.

Watch the video

This English-language video shows what a page learns from navigator.gpu.requestAdapter() before any shader runs. A local lab page declares three adapter reports, one with no adapter at all, and the same call reads each. The same page then reads the browser's own report in official Google Chrome 155 on Windows, which lists an adapter and eighteen features, and in Chrome 154 on Ubuntu, where the call resolves to null. It ran once and the cause was not tested, so it shows that reports can differ and nothing about any other system. No BotBrowser profile is involved. The audio is English.

Introduction

WebGPU is the successor to WebGL, providing modern, low-level access to GPU hardware for rendering and compute workloads. As browsers adopt WebGPU, it introduces a new fingerprinting surface that privacy-conscious users need to be aware of. The API exposes GPU adapter information including the vendor, architecture, device description, feature set, and detailed capability limits. This information is richer and more structured than what WebGL provides, making it a growing concern for anyone who values their online privacy. BotBrowser can keep WebGPU adapter info, features, and limits consistent with a loaded profile in a controlled context; it cannot make unsupported GPU hardware or WebGPU behave like a different device.

For privacy researchers, automation engineers, and anyone concerned about browser fingerprinting, WebGPU represents a significant new source of device identity leakage.

Privacy Impact

WebGPU is a relatively new API (shipping in Chrome since version 113), but its fingerprinting implications are already significant. Although the WebGPU specification was designed with some privacy considerations, including reduced-resolution adapter info by default, the combination of available signals still provides meaningful entropy that can be used for tracking.

Record Chrome 113, vendor, architecture, and maxTextureDimension2D when comparing this surface; those are observable fields, not a hardware identity.

The GPU information exposed by WebGPU includes vendor, architecture, and device fields. While these are intentionally less detailed than WebGL's raw renderer strings, they still distinguish between GPU families. Different GPU vendors, integrated versus discrete GPUs, and different architectures all produce distinct values that narrow down your device configuration. For what an adapter represents and when it may be unavailable, see WebGPU Adapter Information and User Privacy, which covers availability boundaries and privacy-aware fallbacks.

Beyond basic adapter info, WebGPU exposes a detailed set of capability limits: maximum texture dimensions, maximum buffer sizes, maximum compute workgroup sizes, and dozens more. These limits vary between GPU vendors, architectures, and driver versions. The combination of these limit values creates a GPU capability fingerprint that is often more granular than the adapter info itself.

Early research from browser privacy teams has noted that WebGPU's limit values can distinguish between specific GPU generations within the same vendor family. Two GPUs from the same manufacturer but different product lines report different limits, even though they share the same vendor identifier. This level of granularity is concerning for privacy because it narrows identification to specific hardware models.

Growing Importance

As WebGPU adoption increases, particularly for AI inference, advanced visualization, gaming, and creative applications, the API will become standard across modern browsers. This means that WebGPU fingerprinting will become more prevalent, and the absence of WebGPU may itself become a distinguishing signal. Proactive protection is essential.

Why This Matters for Your Privacy

GPU Identity Exposure

Your GPU is one of the most distinctive pieces of hardware in your computer. The combination of vendor, architecture, and capability limits creates a hardware fingerprint that is difficult to change and persistent across browsing sessions. WebGPU makes this information directly queryable by any website, without any permission prompt or user notification.

Cross-API Correlation

A critical privacy concern is the correlation between WebGPU and WebGL. Both APIs access the same GPU. If the GPU identity reported by one API does not match the other, or if the capability profiles are inconsistent between the two APIs, the mismatch itself becomes a strong tracking signal. Websites that query both APIs can detect inconsistencies, which is why any protection approach must address both APIs together. For how WebGL exposes the same GPU identity and what profile consistency means there, see WebGL Fingerprinting: GPU Identity and Browser Protection, which covers the WebGL signal families and common protection approaches.

Feature Set as Fingerprint

The set of GPU features available through WebGPU (such as texture compression formats, depth clipping, timestamp queries, and shader capabilities) varies between GPU models and driver versions. The specific combination of supported features acts as an additional fingerprinting dimension that supplements the adapter info and capability limits.

Rendering Output Variations

Like WebGL, WebGPU rendering produces GPU-specific output. Compute shaders, rendering pipelines, and texture operations all produce results that vary at the numerical level between GPU architectures. While WebGPU's specification is stricter about precision than WebGL's, implementation differences still exist and can be used for fingerprinting. For how to confirm these rendering signals across software and hardware rendering, see Browser Privacy Validation Across Rendering Backends, which covers a rendering matrix for validating Canvas, WebGL, and WebGPU.

Common Protection Approaches and Their Limitations

Disabling WebGPU is currently the simplest protection. Since WebGPU is relatively new, most web content does not require it. However, as adoption increases, disabling it will become increasingly impractical. The absence of WebGPU will also become a distinguishing signal as the API becomes standard, potentially making your browser more identifiable rather than less.

Blocking individual API methods only addresses part of the fingerprint. The feature set and capability limits remain available and provide significant entropy on their own. Partial protection is often worse than no protection because it creates inconsistencies.

JavaScript-level modification of adapter info changes the reported vendor and architecture but does not change the actual capability limits or rendering behavior. A website that checks both adapter info and limits can detect the inconsistency immediately. Surface-level approaches create new detection signals rather than removing existing ones.

Standardizing limits (reporting minimum required values for all limits) would reduce the fingerprint surface but might break WebGPU applications that depend on higher capabilities, degrading the user experience.

The practical approach is to review adapter info, features, limits, and rendering behavior as one declared configuration. BotBrowser exposes selectable profile, real, and disabled modes for that review; the result still depends on the browser build, host, permissions, and page workload.

BotBrowser's Profile-Managed Approach

BotBrowser exposes WebGPU behavior through profile-managed launch settings. These settings describe what a page may observe in the supported build; they do not grant a missing host capability, modify browser internals, or prove that a physical GPU matches a profile.

Complete Adapter Info Control

When a profile is loaded, record the adapter fields that the page actually receives: vendor, architecture, device, and description. Values can be unavailable or differ with the build, host, permissions, or profile data, so treat them as an observed configuration rather than proof of physical hardware.

Feature Set Control

Record the feature names returned by the adapter and compare them with the selected profile and mode. The list is bounded by the supported browser and host; a profile does not add features that the host or build cannot expose.

Capability Limits Control

Record the limits returned by the adapter, such as texture dimensions, buffer sizes, and workgroup sizes. Compare them only within the same build, host, profile, and fixture; they are observed capability values, not a guarantee about a specific GPU model.

WebGL-WebGPU Consistency

With compatible WebGL and WebGPU settings, compare the vendor and other shared signals reported by both APIs. The APIs may still differ because of host and implementation conditions, so verify the loaded profile rather than assuming cross-API identity.

Rendering Output Control

When combined with --bot-noise-seed, repeat the same rendering fixture to check deterministic output for that session. This does not promise a particular physical GPU's numerical behavior or remove all rendering-based signals.

Configuration and Usage

Basic WebGPU Protection

WebGPU protection is automatic when loading a profile:

chrome --bot-profile="path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

WebGPU Configuration Options

BotBrowser gives you explicit control over WebGPU behavior through the --bot-webgpu flag:

# Use profile's WebGPU settings (default, recommended)
chrome --bot-profile="path/to/profile.enc" \
       --bot-webgpu=profile

# Use real system GPU for WebGPU (when you need actual GPU performance)
chrome --bot-profile="path/to/profile.enc" \
       --bot-webgpu=real

# Disable WebGPU entirely (removes the fingerprinting surface)
chrome --bot-profile="path/to/profile.enc" \
       --bot-webgpu=disabled

Combined WebGL and WebGPU Configuration

For the strongest fingerprint protection, configure both GPU APIs together:

# Both APIs use profile data (recommended for consistency)
chrome --bot-profile="path/to/profile.enc" \
       --bot-webgl=profile \
       --bot-webgpu=profile \
       --bot-noise-seed=42

This ensures complete GPU identity consistency across both APIs, with deterministic rendering output through the noise seed.

Playwright Integration

const { chromium } = require('playwright');

const browser = await chromium.launch({
  executablePath: 'path/to/botbrowser/chrome',
  args: ['--bot-profile=path/to/profile.enc', '--bot-webgpu=profile', '--bot-noise-seed=42'],
});

const page = await browser.newPage();
await page.goto('https://example.com');

// Verify WebGPU identity matches the profile
const gpuInfo = await page.evaluate(async () => {
  if (!navigator.gpu) return 'WebGPU not available';
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) return 'No adapter';
  const info = await adapter.requestAdapterInfo();
  return {
    vendor: info.vendor,
    architecture: info.architecture,
    device: info.device,
    features: [...adapter.features],
    maxTexture2D: adapter.limits.maxTextureDimension2D,
  };
});
console.log('WebGPU identity:', gpuInfo);

Puppeteer Integration

const puppeteer = require('puppeteer');

const browser = await puppeteer.launch({
  executablePath: 'path/to/botbrowser/chrome',
  defaultViewport: null,
  args: ['--bot-profile=path/to/profile.enc', '--bot-webgpu=profile'],
});

const page = await browser.newPage();
await page.goto('https://example.com');

// Your WebGPU identity is now protected by the profile

Verification

After launching BotBrowser with a profile, verify your WebGPU protection:

Adapter info check. Verify the vendor, architecture, and device match the profile's target GPU. They should reflect the profiled device, not your actual hardware.

Feature set check. Confirm that the listed features match the expected features for the profiled GPU. The set should be complete and accurate.

Limits check. Verify several limit values and confirm they match the profiled GPU's capabilities. The values should be specific to the GPU model in the profile, not generic minimums.

WebGL-WebGPU consistency. Compare the GPU vendor reported by WebGL with the vendor reported by WebGPU. They should indicate the same GPU family, ensuring cross-API coherence.

Cross-session stability. Run the same WebGPU queries across multiple sessions with the same profile. All values should be identical every time, demonstrating that your GPU fingerprint is stable and reproducible.

You can use fingerprint testing websites or BotBrowser's built-in verification tools to confirm these signals are properly aligned.

Best Practices

• Keep WebGL and WebGPU settings aligned. Both APIs expose GPU identity. Use --bot-webgl=profile and --bot-webgpu=profile together to ensure cross-API consistency. Mismatched GPU identities between the two APIs are a strong tracking signal.

• Use profiles with WebGPU data. Not all profiles include WebGPU information (older profiles may predate WebGPU). Use current profiles that include WebGPU adapter data to ensure complete protection.

• Consider disabling WebGPU if not needed. If your use case does not require WebGPU, --bot-webgpu=disabled removes the fingerprinting surface entirely. This is a valid choice while WebGPU adoption is still growing, though it may become less viable as the API becomes standard.

• Combine with --bot-noise-seed for rendering output. Adapter info and limits are deterministic from the profile. Rendering output also needs the noise seed for determinism. Using both together provides the most comprehensive GPU fingerprint protection.

• Test WebGPU availability. Some profiles may not support WebGPU (matching devices where WebGPU is not available). Verify that your profile includes WebGPU data if your application needs it.

FAQ

Q: Is WebGPU available in all browsers? A: As of early 2026, WebGPU is available in Chrome/Edge (since version 113), Firefox (behind a flag in some versions), and Safari (partial support). Availability varies by platform. BotBrowser profiles specify whether WebGPU should be available based on the profiled device, giving you accurate representation of real-world browser configurations.

Q: How does WebGPU fingerprinting compare to WebGL fingerprinting? A: WebGPU provides more structured adapter info and more detailed capability limits, while WebGL provides raw renderer strings and rendering-based fingerprints. Both APIs are important for comprehensive GPU fingerprint protection. BotBrowser protects both through its profile system, ensuring your GPU identity is consistent across all graphics APIs.

Q: Can I use WebGPU for compute workloads with BotBrowser? A: Yes. BotBrowser's WebGPU control operates at the identity and capability reporting level. Actual compute execution uses your real GPU hardware for performance. You get full GPU performance for your workloads while maintaining a protected fingerprint identity.

Q: What if my profile does not include WebGPU data? A: If the profile does not include WebGPU data and --bot-webgpu=profile is set, WebGPU may not be available (matching a device where WebGPU is not supported). Use a newer profile that includes WebGPU data if you need WebGPU access.

Q: Does disabling WebGPU affect WebGL? A: No. WebGL and WebGPU are independent APIs. Disabling WebGPU does not affect WebGL functionality. Each is controlled by its own --bot-* flag, giving you granular control over your GPU fingerprint.

Q: Are WebGPU compute shader results affected by the noise seed? A: When --bot-noise-seed is set, rendering and compute output that could be used for fingerprinting includes deterministic variation. Normal compute workloads that do not touch fingerprint-sensitive surfaces are unaffected. Your scientific or AI compute workloads remain accurate while your fingerprint is protected.

Summary

For acceptance, compare one adapter row, one featureCount, and the relevant limit fields in each selected mode. Availability and observed values remain dependent on the build, host, permissions, and workload; --bot-webgpu selects a mode, not a hardware identity.

For related topics, see What is Browser Fingerprinting, WebGL Fingerprint Protection, Canvas Fingerprinting, and Deterministic Browser Behavior.

Beyond the reference page

The reference page lists selectable WebGPU modes. The added matrix compares adapter availability, feature names, and limits in profile, real, and disabled modes, then checks WebGL separately. A profile report is not evidence that the host GPU executed the same workload.

For a reproducible run, save the mode, profile identifier, browser build, adapter request result, feature names, and the limits that the page actually received. Run the same fixture twice without changing the host, then repeat it after changing only the mode. A null adapter in disabled mode is an expected capability result; a null adapter in profile or real mode needs a host and permission check before it is interpreted as a privacy result. The cross-check against WebGL is useful because two APIs can expose different views of the same graphics context.

When a graphics application fails, first decide whether it requires WebGPU or can use a WebGL fallback. Then compare the recorded adapter, feature, and limit fields with the application error and host logs. This keeps a compatibility decision separate from an identity decision, and it prevents a profile observation from being presented as proof of a physical GPU or of a site classification.

The smallest useful report is a row per mode, with the same page origin and the same request options in every row. Include whether the adapter promise resolved, the adapter class, the feature count, and the limits relevant to the workload. This makes a release-to-release change visible even when the page does not expose a friendly error message.

If the values change between runs, preserve both rows and note the first changed field. That evidence is more useful than a single screenshot because it shows whether the difference is availability, a declared capability, or rendering behavior.

For a team handoff, attach the page origin, query options, profile identifier, release, host class, and the exact row that changed. Keep a second run with an unchanged host as the control. The row remains a compatibility record, not a claim about a person or a physical device.

The handoff row should also carry adapterClass, featureCount, and firstChangedField so a reviewer can reproduce the comparison.

Practical conclusion

Decide per workload whether it needs WebGPU or can fall back to WebGL, then pick profile, real or disabled mode and keep the WebGL and WebGPU settings aligned. Record one row per mode with the adapter result, feature names and limits, and rerun on an unchanged host as the control. When values change, report the first changed field so availability, declared capability and rendering behavior stay separate.

Sources

• Reference
• Reference