A canvas test draws a known scene and reads the resulting pixels. If two runs return different hashes, something about the input or the rendering path changed. That observation is useful. It does not tell you how many people share your browser, whether a website recognised you, or whether your setup is anonymous.
The practical question is narrower: can this browser repeat this drawing under the same conditions, and which controlled change alters its output? You can answer that with a small experiment, an exported baseline and a record of your settings. You do not need to disable every privacy feature or compare a list of unexplained scores.
Know which bytes the test measures
The canvas fingerprint tool creates a 360 by 120 pixel drawing, reads its pixel buffer and computes SHA-256. It repeats the operation and compares the two digests. The hash is a compact identifier for the measured bytes. It is not a count of browser features and contains no built-in meaning about privacy.
There are four channel bytes per pixel in the readout: red, green, blue and alpha. For this drawing, 360 multiplied by 120 multiplied by four gives 172,800 bytes. A change to one channel can change the digest completely. Looking at the number of different characters between two hashes therefore cannot tell you how visually different the drawings are.
The scene includes drawing instructions and text. Text rendering can depend on font availability, font substitution, operating system libraries and browser implementation. Graphics processing and deliberate readout protections can also affect the result. The relevant input is the complete drawing procedure plus the environment that executes it, rather than the browser name alone.
Make the first comparison boring
Start in an ordinary window with the settings you actually use. Record the browser version, operating system, profile, zoom and whether hardware acceleration is enabled. Note any privacy extension that can modify canvas access. Run the tool and export the report. Run it again without changing a setting. Keep both reports even if the displayed hashes match.
The tool already makes two measurements per run. Repeating the complete run checks another boundary: a later operation in the same document. Next, reload the page and repeat. These are different comparisons. A browser could return stable data within one document while changing the value for a new document, session or site.
Use the same tool version and drawing dimensions. Comparing a digest from another website is usually meaningless because its scene, fonts, image size and byte encoding may differ. Two sites can observe the same browser and produce unrelated hashes simply because they ask it to draw different things.
| Comparison | Keep fixed | What it helps investigate |
|---|---|---|
| Two samples in one run | Document and settings | Immediate readout consistency |
| Two runs before reload | Profile and page | Consistency across operations |
| Run after reload | Profile and tool version | Document-dependent behaviour |
| Fresh private window | Browser and drawing | Profile or session differences |
| One changed privacy setting | All other recorded settings | A possible effect of that setting |
Change one variable and keep a way back
Suppose your normal profile returns the same digest in four runs, but a private window returns a different stable digest. That supports a statement about these two contexts. It does not identify the cause yet. Private windows may use different extensions, storage boundaries or browser protections. Record those differences before attributing the result to a particular privacy mechanism.
If you want to examine an extension, use a disposable profile and a harmless page. Make one run with the extension enabled, one after changing its canvas setting, and another after restoring the original setting. A return to the original result makes the relationship more persuasive, though it still does not establish how the extension behaves on every website.
A browser update is another useful boundary. Save the old report before updating and repeat afterwards with the same profile. The result can change because of rendering fixes or library changes without any new tracking feature. Keep the browser build in the record so that a later comparison does not confuse an update with a setting change.
Read stable, changing and unavailable results separately
A stable readout means the observed bytes matched. Other browsers may produce those same bytes. Without a representative population and a defined collection method, there is no basis for a uniqueness percentage. Even a population comparison would describe that dataset and its time period, rather than every device on the internet.
A changing readout can be intentional protection, a changing input or an unstable rendering path. First confirm that the test itself stayed constant. Then repeat at the document and session boundaries described above. Do not treat changing output as proof that all tracking is prevented; a site may use cookies, account identifiers or other browser signals.
An unavailable readout is a third state. Context creation may fail, access may be restricted, or the browser may decline the operation. Preserve the exact error and context. Replacing an error with a zero hash or a reassuring label would hide useful information. A blocked measurement says something about that operation, not about the entire browser.
Separate display appearance from readable pixels
Canvas has a backing bitmap and a size at which that bitmap is displayed. CSS can stretch a drawing without changing the bitmap dimensions that the tool reads. Conversely, an application can resize its backing store for device pixel ratio, which changes the pixel buffer even if the visible element looks the same size.
This distinction matters when reproducing a report from a different test. Ask whether it measures raw image data, an encoded PNG or a data URL. PNG encoding can introduce another layer of differences. A hash of encoded image bytes and a hash of the pixel buffer are different measurements and should have different labels.
For visual debugging, compare the rendered image alongside the metadata. Missing text may indicate a font or draw failure. A matching-looking preview with a changed hash may reflect tiny channel differences that are hard to see. The digest provides equality evidence; inspecting the underlying image helps explain the kind of difference.
Keep the report proportionate to the issue
A useful issue report includes the test name, browser build, dimensions, whether each pair matched and the smallest setting change that reproduced the difference. Include the digest only when the recipient needs to compare exact results. A public collection of persistent browser measurements can itself become identifying data, so avoid publishing a complete browser profile for a simple drawing bug.
Describe your conclusion precisely. For example: the two canvas samples matched in the normal profile; samples differed after each reload in a separate test profile with a specified setting. That is reproducible and bounded. Saying the browser has become untrackable goes beyond what this experiment measured.
Check a font substitution before blaming the GPU
A drawing that asks for Georgia can use a different font if the requested face is unavailable. Before comparing two machines, confirm which fonts the drawing requests and whether those fonts are installed. A browser can successfully render text through a fallback without reporting a canvas error.
For your own application, create a second controlled scene containing only filled rectangles and curves. Compare its stability with a text-only scene. If the shapes remain stable while the text changes, the split narrows the investigation toward text rendering. It does not prove a single library is responsible, but it gives the next experiment a clear target.
Wait for any web fonts used by your application before drawing the reference scene. A first draw made with fallback text and a later draw made with a loaded font are different inputs. Record that loading boundary alongside the hashes.
Frequently asked questions
Does a matching hash mean two people have the same computer?
No. Matching hashes indicate matching measured bytes, subject to the usual limits of digest comparison. Many systems can render the chosen scene identically. This test has no hardware ownership database and no reference population. It cannot establish that two visits came from the same person, even when a website combines the result with other observations.
Can canvas read my files or photograph my screen?
This tool draws its own scene and reads that canvas. It does not inspect local documents or capture the desktop. A canvas can contain images that an application loads, but reading pixels is also subject to origin restrictions. Screen capture is a separate capability with its own user interaction and permission model.
Should I block canvas everywhere?
Decide based on your browsing needs and the browser's available protections. Canvas supports charts, image editors, maps and games, so a blanket block can break useful features. Start with supported privacy settings, then check sites you rely on. A test can help describe the effect of a setting, but it cannot choose the right balance for every user.
Why did changing zoom have no effect?
The tool reads a fixed-size backing bitmap. Browser zoom can alter presentation without altering the drawing instructions or that bitmap. Other tests may explicitly include device pixel ratio or viewport size and behave differently. Record the measured dimensions before expecting a zoom change to produce a different digest.
Can I compare this result with WebGL or audio hashes?
Keep each measurement in its own comparison series. Canvas pixels, WebGL metadata and offline audio samples are different inputs. Their hashes are not interchangeable, even when all use SHA-256. The browser fingerprint tool can collect several signals together, but its combined digest still describes a snapshot, without measuring anonymity.