Tej strony nie ma jeszcze w Twoim języku. Czytasz tekst angielski.
Glossary
WebGL fingerprint
A WebGL fingerprint is an identifier a site builds from the strings your graphics card reports and the image it renders.
How a site reads the card
WebGL exists so pages can draw with the graphics card. The same calls that draw also report what is doing the drawing, and that report is far more specific than anything else on the page.
A full reading takes a few milliseconds and shows nothing on screen. The frame is rendered off screen and thrown away once its bytes have been taken.
- 1
Asks the card its name
An extension hands over the unmasked vendor and renderer strings, which together name the chip, the driver and the graphics layer beneath it.
- 2
Draws a small frame
A triangle over a flat fill is enough. Two cards given the same instructions do not land on the same bytes.
- 3
Reads the frame back
The pixels leave either through the graphics calls or through a copy onto a canvas, and both roads end in one hash.
Your graphics card right now
These values are read in your browser on this page. The renderer string is often enough on its own to name the chip and the driver behind it.
Nothing here leaves this page. The reading is drawn on the spot, and no request goes out with it.
Twoje urządzenie, w tej chwili
- WebGL vendor
- pomiar na Twoim urządzeniu
- WebGL renderer
- pomiar na Twoim urządzeniu
- Canvas hash
- pomiar na Twoim urządzeniu
Odczytane w Twojej przeglądarce i pokazane tutaj. Nic nie jest nigdzie wysyłane.
Two readings not one name
Most tools in this category edit the two strings and stop. That is half the reading, and the other half is produced by the hardware itself.
The four parts below are read by one page in one pass. They have to agree with each other, and agreement is what a set of edited strings cannot supply on its own.
The vendor string
It names the maker as the browser reports it. Our acceptance run pins it to the profile seed and compares the answer by name.
The renderer string
It carries the chip, the graphics layer and the shader levels in one line, which makes it the most specific single value a page can read.
The rendered frame
Bytes produced by the hardware do not follow an edited string. A page that reads both then holds a contradiction rather than a name.
The road the pixels take
Pixels leave the drawing buffer directly or through a copy onto a canvas. A defence applied to one road is found by taking the other.
What the shipping build answers
The numbers below come from the run of 2 September, on the build shipping today. Each is one line in the harness and each reports its own value rather than a verdict.
The run is given four seeds and repeats the whole set for each of them. A defence that holds for one seed and fails on another is not yet a defence.
The parameter reader stays native
The function that answers questions about the card still reads as native code, so a wrapper around it is not there to find.
native codeBoth roads give the same bytes
Pixels taken straight from the drawing buffer and pixels taken through the pack buffer come back identical.
0 apartThe frame is not raw
A flat fill read back from the drawing buffer differs from the clean fill in four hundred and seven places.
407 changed
What our engine does
Both strings arrive with the profile seed on the launch line, and the frame is altered where the card hands it over. The two therefore move together instead of pointing at two different machines.
Two runs of the same harness: the build before the fingerprint patches, and the build shipping today. Rows that a run did not reach are named as such rather than left blank.
| Measurement | Before, 25 Aug 2026 | Shipping, 2 Sep 2026 |
|---|---|---|
| WebGL frame against its canvas copy | 109 bytes apart | 0 bytes apart |
| Pixels straight from the drawing buffer | same as with no seed | 407 off a flat fill |
| Pack buffer road against the direct one | not measured | 0 bytes apart |
Often confused with
Canvas fingerprint
That surface is drawn by the browser in two dimensions and this one by the card. Different values, different code and a separate defence.
WebGPU
The newer interface reaches the same hardware through its own calls and is read on its own. A build can hold one road and leave the other open.
The renderer string on its own
Editing the two strings leaves the drawn frame where it was. The reading is the pair, and a page can take both in one pass.
The card named in system settings
What the operating system calls your card and what the browser reports are two different strings. A page reads only the second one.
How to check your own
The panel above shows what the browser you are reading this in reports. The self-test lives in the app and runs inside a profile, against the engine that profile launched.
It names the strings the seed asked for and prints what came back, so a mismatch is visible as two lines rather than a score.
Run it in two profiles on one computer. Two cards where there is one machine is the reading worth having, and one run shows both.
What this does not do
- It does not turn one graphics card into another. The strings and the drawn frame answer as a set, and the set has to stay plausible next to the profile.
- It does not cover WebGPU on its own. That interface reaches the same hardware through its own calls and is patched apart from this.
- It does not hide that WebGL exists. A browser answering with nothing is rarer than any card and marks itself at once.
- It does not make a profile anonymous. Behaviour, address reputation and account history close more accounts than any card string does.
Check it
Every number above comes from a file you can open.
- The WebGL checks the self-test runs
- apps/desktop/src/lib/fpAudit.js
- The two runs quoted above
- docs/замеры/приёмка-до-заплат-25-08.log · docs/замеры/приёмка-windows-02-09.log
- A build is not accepted until these hold
- engine/scripts/engine-invariants.js · engine/scripts/accept-engine.js
- The checks run in a real browser
- apps/desktop/test/fp-audit.js · apps/desktop/test/audit-on-builtin.js
Questions
- Does the renderer string give away my real card?
- In our engine both strings come from the profile seed, and the acceptance run compares the answer against that seed by name. The panel above shows what your current browser reports.
- Why measure the read path twice?
- Because pixels leave the card by two roads, and a defence applied to one is found by taking the other. The run compares the bytes from both.
- Do two profiles report two cards?
- Yes, on our engine: the strings and the frame both follow the seed of the profile. The self-test prints the expected strings next to the ones that came back.
- Is WebGPU covered by the same work?
- It is a separate road with its own patch. On a build host with no graphics device the run says that line could not be measured instead of passing it quietly.
- Can I just switch WebGL off?
- You can, and a browser without it is rarer than any particular card. The refusal becomes the trait that identifies the machine.
Next to this
See what your own profile answers
The self-test runs inside a profile and reports every check by name, green and red alike.