| Component name | wgsl_features |
|---|---|
| In the visitorId | no (reported, kept out of both ids) |
| structuredId group | none |
| Hashing | always a digest, except the plain value none when nothing is found |
| Excluded under | no browser class |
| Inner timeout | 1000 ms |
| Added in | signalsVersion 11 |
| Collector revision | 1 (reported as revision with every result) |
WebGPU programs are written in a shading language called WGSL. As browsers add language features, they list them in navigator.gpu.wgslLanguageFeatures. WhiskerJS reads that list (presence only) and turns it into one short code.
What it reads
navigator.gpu.wgslLanguageFeatures, a set of feature names such as readonly_and_readwrite_storage_textures or packed_4x8_integer_dot_product. No adapter, no device, no shader compilation.
How the technique works
The names are sorted, joined with commas and hashed. An empty set reports the plain value none. Without navigator.gpu or without the set the component is unavailable / no_api.
Why it helps
The list grows with browser releases and differs between engines, so it dates the browser’s WebGPU implementation independently of the user agent. On your server it is a lie detector: a browser that claims an old version but lists a newer feature is unusual. In the hosted CI runs of PR #29, Chromium 153 and Chrome 155 gave different digests.
Stability
It changes with browser updates that add WGSL features and is the same between sessions in one version. Reported outside both ids. Added in library PR #29 (2026-10-27) at signalsVersion 11: it is outside both ids, so adding it changed no id and needed no version bump.
Browser support and what blocks it
- Chromium-based browsers expose it with
navigator.gpu, even without a GPU:okin Chromium 153 and Chrome 155 in CI, the same in every collection. unavailable/no_apiwithoutnavigator.gpu: headless Firefox and WebKit on Linux in CI. Firefox and Safari versions with WebGPU enabled report it too.- No browser class excludes it.
Privacy
It describes the browser’s shader compiler, not the device or the user. No prompt, no request, and it leaves the library only as a digest.
How WhiskerJS handles noise and failures
| Status | ruleId | When |
|---|---|---|
ok |
a digest, or none for an empty set |
|
unavailable |
no_api |
no navigator.gpu or no wgslLanguageFeatures |
unavailable |
no_digest |
no Web Crypto |
blocked |
threw, security_error |
a read threw |
excluded |
caller_excluded |
you excluded it |
timed_out |
timeout, aborted |
budget or abort |
Example value
"wgsl_features": { "status": "ok", "value": "9a0d6c3e51b74f28c6e1a9d40b3f7e25", "hashed": true, "durationMs": 0.1, "revision": 1 }
Questions and answers
Does wgsl_features need a GPU?
No. The list describes the browser's WGSL compiler and is read straight from navigator.gpu, without an adapter or a device. Chromium reports it even on a machine with no GPU.
Why is it not in the visitorId?
Browsers add language features in new releases, so the value changes with updates. It is reported for your server as a version and engine hint.