WebGL fingerprinting: what your GPU reveals

The short version

Modern browsers can draw fast 3D graphics for games and maps, using a feature called WebGL. The catch: the same feature lets a web page read the name of your graphics chip and draw a tiny 3D image whose exact pixels are unique to your hardware. That becomes a hidden ID — no cookie required. A couple of free browser choices make it far less useful to trackers.

What's actually happening

Think of your graphics card as an artist with a very particular style. Ask a hundred artists to paint the same simple scene and each one's brushwork comes out slightly different. A tracking script does exactly that: it asks your browser to render a small 3D shape, then reads back the pixels. Your specific GPU, its driver, and your operating system shape those pixels in a consistent, recognizable way.

Worse, WebGL will often just tell a site your graphics hardware by name — something like "NVIDIA GeForce RTX 3060" or "Apple M2." That label alone narrows down who you are.

Why it matters to you

• It works in private/incognito mode and survives clearing cookies.
• The GPU name plus the rendered image is a strong, stable clue to your exact device.
• Ad and analytics scripts hidden on many sites can use it to recognize you across them.

On its own it won't name you personally, but combined with other clues it helps track you. You can weaken it.

How to fix it

Like canvas, this isn't fixed on the website or in Windows — you pick a browser that either scrambles the result or makes you look like everyone else.

Option A — Brave (easiest)

1. Use Brave with its default Shields on. It randomizes WebGL readings and limits what the page can learn.
2. Confirm by clicking the Brave lion in the address bar and checking that fingerprinting protection is active.
3. Leave the default setting alone — that's the one that works.

Option B — Firefox

1. Set tracking protection to Strict in Settings → Privacy & Security. This blocks many known fingerprinting scripts before they can probe WebGL.
2. Firefox's stronger "Resist Fingerprinting" mode also masks the GPU name, but it has side effects (wrong clock, forced English, odd margins). Most people should stay on Strict.

Option C — Tor Browser (blends into a crowd)

1. Install Tor Browser from torproject.org.
2. It hides your real GPU name and standardizes WebGL so everyone looks alike. Use it as-is — no resizing, no extensions.

On phones

Brave on Android and iPhone carries the same protection. On iPhone and iPad, every browser uses Apple's engine, and Safari already hides a lot of GPU detail, so you're reasonably covered there.

A warning about extensions

Add-ons that "spoof your GPU" can make you more identifiable, because almost nobody else runs that exact add-on with that exact fake value. Prefer a browser that does this by default.

How to check it worked

Run this site's test in Brave or Tor. The GPU name should read as hidden, generic, or scrambled rather than your real card, and your grade should improve. You can also compare two separate private windows — a protected browser won't hand both the same WebGL ID.

If your result was already good

If you scored an A or B, your browser is already masking or scrambling your GPU details — nothing to install or change. Keep it updated and resist adding niche "spoofing" extensions that could undo the benefit.

Want to go further?

The Advanced version shows the exact values WebGL leaks — the unmasked vendor/renderer strings, parameters, and shader precision — and how Brave's randomization and Tor's uniformity each handle them.

What WebGL fingerprinting actually is

WebGL fingerprinting combines two signals. First, metadata: a script queries the WebGL context for parameters, supported extensions, shader precision formats, max texture sizes, and — most damaging — the UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL strings exposed via the WEBGL_debug_renderer_info extension. On Windows these typically surface an ANGLE string like ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 Direct3D11 vs_5_0 ps_5_0), naming GPU and backend. Second, rendering: the script draws a scene (often with gradients, textures, and anti-aliasing) to an offscreen buffer and hashes readPixels() output, which varies by GPU, driver, and float handling. Together these are high-entropy and stable, and require no permission or storage.

Why it matters

The renderer string alone can place you in a small hardware cohort; the rendered-pixel hash refines it further. Both persist through incognito and cookie clearing, and an embedded third-party script computes the same values across every site it rides on. WebGL is one of the strongest components in a composite fingerprint precisely because the GPU is a durable hardware trait.

Defenses by browser

Brave — randomization

1. Brave farbles WebGL readback and parameter output using its per-session, per-eTLD+1 seed, so the pixel hash and some values are non-reusable across sites and sessions.
2. Brave also restricts the unmasked vendor/renderer so scripts don't get your true GPU name under the default Shields setting.
3. Edge case: within one site in one session the values are stable (needed for compatibility), so Brave defeats cross-site/cross-session linkage rather than in-session sampling.

Firefox — RFP and WebGL hardening

1. With privacy.resistFingerprinting=true, Firefox masks the unmasked vendor/renderer (reporting generic values) and reduces other distinguishing readouts, as part of its broader spoofing suite.
2. Firefox historically gated WEBGL_debug_renderer_info behind the pref webgl.enable-debug-renderer-info; disabling it removes the GPU name but is itself a (small) distinguishing choice.
3. In default (non-RFP) browsing, protection is list-based — Disconnect's fingerprinting list under ETP Strict — not WebGL randomization. Trade-off: RFP's side effects (timezone, locale, letterboxing) and a smaller RFP cohort.

Tor Browser — uniformity

1. Based on Firefox ESR with RFP on, Tor masks the renderer and presents standardized WebGL so same-version/same-platform users converge on one value.
2. Some builds minimize or disable high-entropy WebGL surfaces entirely; the goal is crowd uniformity, not noise. Cost: breakage of WebGL-heavy sites and the usual Tor latency.

OS and hardware reality

• ANGLE backend matters: Chrome/Chromium on Windows renders WebGL through ANGLE over Direct3D by default, so the renderer string encodes both GPU and translation layer. macOS uses Metal; Linux uses native GL or ANGLE-over-Vulkan. The same GPU reports differently per OS.
• Software fallback (SwiftShader/llvmpipe) yields a distinct, consistent output and is itself identifying — don't assume disabling the GPU helps.
• iOS/iPadOS: all browsers are WebKit; Safari exposes less GPU detail, so Apple mobile devices fingerprint more uniformly.
• Android Chrome offers no WebGL defense; Brave for Android farbles as on desktop.

Verify properly

• Check browserleaks.com/webgl for the raw unmasked vendor/renderer and parameter report, plus this site's test and coveryourtracks.eff.org.
• Brave: expect masked vendor/renderer and a pixel hash that changes across sessions. Firefox RFP: expect generic vendor/renderer. Tor: expect the known uniform value for your platform.
• Confirm the GPU name specifically — it's the single highest-value leak; a scrambled pixel hash with your real GPU name still exposes you.

Trade-offs & gotchas

• Masking the renderer can break sites that pick quality tiers by GPU, and some fall back to slow software paths.
• Rare spoofing extensions backfire: a fake renderer string that nobody else reports is more unique than the truth, and inconsistencies (e.g., an NVIDIA string with Apple shader precision) flag you as spoofed.
• Noise is sampleable: weak per-call randomization can be averaged out; structured farbling resists this better.
• Disabling WebGL entirely (via flags/extensions) removes the surface but is rare enough to be its own signal, and breaks maps and 3D content.
• Every option here is software — no hardware purchase changes your WebGL fingerprint.