What it measures
The signal queries three categories of WebGL data: a curated set of capability-limit parameters (maximum texture and viewport dimensions, vertex attribute and varying counts, and similar caps), a set of shader precision format results across the vertex and fragment shaders, and the full sorted list of supported extension names. Together these form the hash input.
Although the raw GPU hardware determines physical capabilities, browser engines apply their own caps and ship different subsets of optional extensions. Chrome's ANGLE translation layer, Firefox's native OpenGL path, and Safari's Metal backend each report different parameter sets for the same GPU.
How it's collected
The collector creates a 1x1 WebGL context (WebGL2 preferred, WebGL1 fallback) using OffscreenCanvas if available, otherwise a hidden DOM canvas. It reads the capability-limit parameters via getParameter, queries the shader precision formats via getShaderPrecisionFormat, and calls getSupportedExtensions. The extension list is sorted alphabetically and joined into a single string before being included in the hash input.
The collected parts are joined with a delimiter and hashed with xxHash64. The WEBGL_lose_context extension is called after collection on both canvas paths to release GPU resources. Cleanup errors are silently swallowed.
Confidence rules
| Confidence | Trigger |
|---|---|
| normal | WebGL context obtained and data collected |
| absent | No WebGL context available, or top-level catch fires |
Why engine-bound
Browser engines apply their own policy caps on many WebGL parameters independent of the GPU driver. MAX_TEXTURE_SIZE can be limited by policy, extension availability varies between Blink and WebKit, and shader precision format values can differ between Chrome's ANGLE translation layer and Firefox's native OpenGL path. The extension list is especially engine-discriminating because browsers ship different subsets of optional WebGL extensions.
Because the reported values are shaped by the engine, not exclusively by the GPU, the hash differs between Chrome and Firefox on identical hardware. This makes webgl_params a strong per-browser discriminator and a complement to the hardware-bound webgl_gpu_identity signal.
Things worth knowing
- Range-valued parameters (returned as typed arrays) are serialised to a stable string form before being included in the hash input.
- The value field returned to callers contains paramCount and extensionCount as integers, not the raw parameter data.
- Collection is synchronous (no timeouts, no yield points). Typical timing is 5-20 ms.
- WEBGL_debug_renderer_info is not used by this collector; that extension belongs exclusively to webgl_gpu_identity.
Last reviewed 2026-06-04
