Your fingerprint is not your identity.

Start with the collection, not the hash

A browser fingerprint often ends with a long hexadecimal string. That string can look like a precise identity, but it is usually the output of a hash function applied to a collection of measured characteristics. The hash makes the collection convenient to compare. It does not add new evidence about who created the data.

Suppose a page records a language preference, timezone, screen size, graphics renderer and canvas readout. Two sessions that expose the same values can receive the same digest. That observation is compatible with several explanations: the same browser returned, two browsers share a configuration, or a privacy feature standardised the values. Without a suitable dataset and a defined method, a uniqueness percentage would be speculation.

The browser fingerprint tool therefore shows its inputs and calls the digest a snapshot. It does not compare you with a hidden population or turn an unusual renderer into a claim about your identity.

Separate the ways a site can recognise a visit

Fingerprinting is only one recognition mechanism. A login account directly links activity to an account identifier. A cookie or local storage entry can recognise a returning browser without needing to infer much from its hardware. A network address can provide another signal, although shared connections make it unreliable as a person-level identity.

These mechanisms interact. Changing a canvas result while logging into the same account does not make the account connection disappear. Using a VPN can change HTTP egress without changing your language or graphics capabilities. Private browsing can separate temporary storage while leaving many device characteristics unchanged.

Make a small, controlled experiment

Run a baseline scan twice in the same profile. Save the reports and check whether the measured groups are stable. If they already differ, investigate that variation before changing anything. A display transition, browser update or privacy feature can affect the result.

Now change one condition. Enable a documented privacy setting or compare a separate profile, then scan again with the earlier report selected. Look at the changed fields rather than the visual difference between hashes. Cryptographic digests are intentionally sensitive to input changes; two completely different-looking strings may reflect one small changed value.

Record the browser version, operating system and relevant settings. Avoid testing five extensions at once. If the experiment changes too many variables, it can show that the overall setup differs but cannot explain which intervention caused the difference.

A stable result can be a privacy strategy

It is tempting to assume that randomness always improves privacy. Some browser protections do introduce noise or change values between contexts. Others try to make many users expose the same standardised information. Both approaches need careful coordination with the rest of the browser.

A unique collection of unusual overrides can be distinctive even if individual values look less detailed. Disabling features can also break useful applications. Start with a maintained browser’s supported privacy mode and understand its documented trade-offs before assembling a large collection of unrelated spoofing extensions.

Use the canvas comparison and WebGL inspector to study specific observations, but do not treat any one readout as a complete scorecard. A privacy decision should follow the activity you want to protect and the recognition mechanisms involved.

Share only the evidence you need

A fingerprint report can contain screen dimensions, language preferences and graphics details that you would not otherwise publish together. When asking for help, share the changed field and reproduction steps rather than an entire unredacted report. The diagnostic is meant to make your own browser understandable, not to build another public collection of identifying data.

The W3C’s fingerprinting guidance explains the broader design concern: apparently ordinary APIs can expose information that becomes identifying when combined. That is the reason to inspect the collection carefully and keep conclusions proportional to the evidence.

Build a comparison record that survives a browser update

Choose a question before collecting a baseline. For example, you may want to know which fields change when the laptop moves from its internal display to an external monitor. Save the initial report, note the display arrangement and keep the extended-audit option consistent. A later digest comparison is meaningful only when the collected field set is comparable.

Run another scan without moving the window or changing settings. This checks whether the starting state is stable enough for the experiment. If audio or canvas values already vary, mark that field as variable in the baseline. Do not let an unstable field obscure a clear change in screen dimensions.

Move the browser to the other display and repeat. Compare width, height, available screen area and pixel ratio individually. Then return to the original display. If the relevant values return too, the sequence supports a display-related explanation more strongly than a single before-and-after screenshot.

Repeat the same process after a browser update only if that is the next question you need to answer. Keep the old build number, because changed API defaults or rendering libraries can affect the snapshot. An old baseline is useful historical evidence, but it is not a promise that the browser should preserve every value forever.

Treat missing fields as part of the measurement

A browser may reduce a hardware value, omit an optional extension or reject a permission query. Store the unavailable state distinctly from zero, false or an empty string. Those values can have real meanings. A comparison tool that substitutes zero for every failure can create apparent matches that never represented successful measurements.

When two reports collect different fields, compare the common fields and identify the coverage difference. Enabling the deeper audit adds observations that a basic scan did not include. A changed combined digest is expected when the input collection changes, even if every shared field remains identical.

Turn the experiment into a practical decision

Suppose a supported privacy mode hides extra graphics metadata and keeps your essential applications working. That is useful evidence for your own choice. Record the applications tested and the settings used. Avoid converting that local outcome into a claim that the configuration prevents every form of recognition.

If a setting breaks video calls, investigate the specific feature and available browser controls. A separate work profile may fit your needs better than a large collection of overlapping overrides. The decision should account for the activity, account use and network context as well as the fingerprint fields.

Keep comparisons local when possible. A long public history of your browser snapshots can reveal changes in devices, language and display setup. For support, share a minimal field-level difference with a synthetic example where practical. The report format makes inspection easier, but it does not make all collected values appropriate for publication.

Frequently asked questions

Why did the combined hash change when only one field changed?

The combined digest covers the serialised collection of measured values. A small input change can alter the entire digest. Inspect the field comparison to understand the cause. The number of different output characters is not a measure of how much your privacy improved or how different the browser became.

Can two different computers have the same snapshot?

They can expose the same selected values, especially when hardware and browser configurations are common or deliberately standardised. This tool has no population model that converts a match into a person-level conclusion. A snapshot match should remain a statement about the collected values and the measurement method.

Does private browsing erase all fingerprint signals?

Private browsing usually changes storage and session behaviour, with additional protections depending on the browser. It does not imply that every rendering or device capability disappears. Compare the specific fields you care about and read the browser's documented behaviour, while keeping account sign-in and network routing separate.

Should I install several spoofing extensions?

Overlapping extensions can create inconsistent values and compatibility problems that are difficult to diagnose. Start with maintained browser controls and a clear requirement. If you evaluate an extension, use a separate test profile, change one setting at a time and verify the applications you need before adopting it.

Does the audio test record my microphone?

The included extended audit generates an offline audio signal and measures its computed samples. It does not request microphone input. Camera and microphone permission states are separate observations, and a state query does not itself begin recording. Read the operation's documented scope when interpreting an audio-related field.

Can I compare this digest with another fingerprint website?

Only if the input collection, drawing procedures, serialisation and hash algorithm are the same. Different sites usually choose different signals and tests, so unrelated digests do not establish a browser difference. Use a consistent tool and version for an experiment, and compare underlying fields when methods differ.

What should a useful conclusion look like?

State the tested context, the fields that changed, the setting or event applied and whether the result repeated. For example, a display switch changed pixel ratio while language and timezone stayed constant. That gives another person a reproducible observation without inventing a universal anonymity score.

When should I collect a new baseline?

Collect one when the tool's measured field set changes or when you intentionally adopt a new browser environment that becomes your comparison reference. Keep the previous report labelled with its date and version. Do not overwrite history so aggressively that a later investigation cannot distinguish an update from a user setting.