A browser fingerprint drifts as you update software, drivers and fonts. See what changes, what stays, and how trackers re-link a drifted fingerprint.
A fingerprint is not a tattoo. It is a snapshot of how your browser and device look today, and both change: browsers update every few weeks, drivers and operating systems update, you plug in a monitor. So how long does a fingerprint stay useful to a tracker? Short answer: individual values expire quickly, but the overall picture usually changes slowly enough to be followed.
This post is about change you did not cause on purpose. For what survives when you deliberately clear cookies, go incognito or switch on a VPN, see persistent visitor IDs.
Key Takeaways
- A fingerprint is a bundle of many attributes, and each ages at its own speed. Some change with every browser release, others almost never.
- Updates to the browser, graphics driver, operating system and fonts are the usual causes of drift; so are a new screen, a zoom change or travel across time zones.
- Trackers do not need an exact match. If most attributes agree and the differences are explainable, a new fingerprint can be linked to an old one.
- There is no single "expiry date": how long a fingerprint stays linkable depends on how unusual your setup is and how often you change it.
- You can watch your own drift with the "Compared with your last visit" card in BrowserInsight's fingerprint check.
What drifts, and what mostly doesn't
Think of the fingerprint as layers with different shelf lives. The rates below are qualitative; no public page we can cite gives reliable numbers for the whole web.
| Attribute | Typical cause of change | Stability |
|---|---|---|
| Browser version, User-Agent, Client Hints | Every release | Short-lived, but changes in a predictable direction (see User-Agent reduction) |
| Feature set and API support | New browser version (see engine version detection) | Short-lived, monotonic |
| Canvas and WebGL output | GPU driver or OS graphics update | Medium: stable between updates |
| Installed fonts | New apps, OS updates, language packs | Medium |
| Screen size, pixel ratio, zoom | External monitor, window layout, accessibility zoom | Varies by habit |
| Time zone | Travel | Changes on a trip, then returns |
| Platform, CPU class, preferred languages | Hardware replacement, settings change | Long-lived |
The pattern matters more than any single row. A browser version that only ever goes up is not suspicious; a canvas hash that changes on every page load is.
How trackers handle drift
A naive tracker hashes everything and treats a changed hash as a new visitor. A better one compares attributes. If the fonts, platform, languages, screen and GPU all match and only the browser version moved from N to N+1, linking the two visits is a safe bet.
This idea has an academic implementation: FP-Stalker, the code released with the paper by Vastel et al. at IEEE S&P 2018. It follows browser fingerprints over time by matching fingerprints whose differences look like ordinary evolution. We do not quote its accuracy or stability figures here; read the paper for those.
Commercial visitor IDs add a second layer: they combine the fingerprint with stored identifiers, so a drifted fingerprint can be reconnected through a surviving cookie or localStorage value. See FingerprintJS explained for how that works.
Why randomising is not a clean fix
If drift is what breaks linking, why not randomise the fingerprint on every visit? Because randomisation is itself visible. Noise injected into canvas output, for example, tends to produce results that are inconsistent with the claimed hardware; see canvas fingerprint noise. The W3C fingerprinting guidance frames the underlying concern: stable, high-entropy surfaces are what make fingerprinting work, so reducing and standardising what a browser exposes is more robust than disguising it.
How to measure your own drift
- Run the fingerprint check and note the result.
- Come back after a browser update, a driver update or a change of monitor.
- Read the "Compared with your last visit" card. It lists which values changed.
How it works: the page keeps a local snapshot (canvas, WebGL, audio and font-list hashes, User-Agent, engine and version, time zone, languages, screen size) in this browser's localStorage. Nothing is uploaded, and the site holds nothing server-side. It only compares against the previous visit in the same browser, so it cannot follow you across browsers, and you can clear or turn off the snapshot at any time.
For a second opinion on how unusual your setup is at one moment, try Cover Your Tracks (the EFF's explainer covers the method) or AmIUnique. How rare you are today largely decides how long linking works; the maths is in fingerprint entropy and anonymity sets.
Frequently Asked Questions
Does my fingerprint change after a browser update? Yes, at least the version-related parts do. Most other attributes stay the same, which is why the new fingerprint can usually still be linked to the old one.
How long does a fingerprint last? There is no fixed lifetime. A common, unmodified setup blends into a crowd and is hard to follow even when stable; an unusual one stays recognisable through many small changes.
Does clearing cookies reset the fingerprint? No. Cookies and fingerprints are separate; see persistent visitor IDs.
Can I stop drift-based linking? Not entirely. Reducing the unusual parts of your setup helps more than adding noise. Start with the browser fingerprinting guide.
Conclusion
A fingerprint's individual values go stale in days or weeks, but trackers care about the whole pattern, and the whole pattern changes slowly. Treat "it changed after my update" as expected, not as protection. Measure your own drift, and focus on being less distinctive rather than merely different.
