Why a Device ID Changes After a Browser Update

If you rely on device IDs to stop trial abuse or multi accounting, you have probably asked yourself why a device id changes after a browser update. The answer lies in how those IDs are built.

What Exactly Is a Device ID?

A device ID is not a serial number burned into hardware. It is a fingerprint derived from a collection of browser signals: canvas rendering, WebGL, audio, installed fonts, screen resolution, hardware concurrency, locale, time zone, and dozens more. A fingerprinting script captures these signals, hashes them, and produces a value that usually survives a site refresh or a new tab.

But none of those signals is permanent. A browser update can change the renderer behavior, drop a font, or modify default screen metrics. A canvas hash survives a Chrome update; a screen resolution does not. Users also switch browsers, install privacy extensions, or toggle anti fingerprinting modes that deliberately randomise signals. Each change can break the hash and produce a new device ID.

That is why a device ID is best treated as a probabilistic hint, not a guaranteed identifier. It works well enough to catch returning fraudsters, but it can reset. For a deeper look at how fingerprints are assembled and why they shift, read What Is Device Fingerprinting and How Does It Work?.

How a Browser Update Resets Your Fingerprint

A browser update does not erase your data, but it can rewrite the signals a fingerprint is built from. The hash changes when any of the following moves.

• User agent string: Every update increments the version number, and major releases often change the platform or OS token. The string is one of the easiest signals to change.

• Canvas rendering: Canvas hashing depends on how text, shapes, and anti-aliasing are rasterized. A new browser version may use a different graphics stack, font renderer, or hardware acceleration path, which changes the pixel output.

• Installed fonts: Browsers expose font lists through the Font Loading API. An update can change which fonts are available to a page, either through bundled defaults or fallback ordering.

• Screen resolution: The fingerprint reads the current window size, not just the physical display. A browser update can change default window dimensions, or the user simply resizes after the update.

• WebGL: WebGL rendering depends on the GPU, driver, and browser implementation. Updates can change the renderer string, supported extensions, or the exact pixels produced by a shader.

• Audio context: Audio fingerprinting measures how the browser processes and outputs sound. A change in the audio stack, sample rate, or processing pipeline can shift the resulting hash.

Any of these changes can break the match against a previously stored fingerprint. That is why a device id changes after a browser update: it is a probabilistic hint, strong when several signals align, but capable of resetting after a routine update.

Privacy Features That Break Fingerprint Stability

Modern browsers have begun treating fingerprinting as a privacy threat. Firefox, Brave, and Safari ship anti-fingerprinting protections that deliberately randomize or block the signals your fraud detection relies on. A browser update can silently enable these features, causing a device ID to appear as a new visitor.

Firefox's Total Cookie Protection includes fingerprint randomization. It adds noise to canvas rendering, rounds screen dimensions, and limits the number of exposed fonts. When a user updates Firefox and this feature activates, your fingerprint hash shifts even though nothing else on the device changed. Brave goes further. It randomizes the order of signal values in the user agent, adds noise to WebGL output, and spoofs hardware concurrency to hide the true CPU core count. Each request can produce slightly different signal values.

Safari is the most aggressive. Intelligent Tracking Prevention 2.0 and later stripped access to the canvas API by default, blocks audio fingerprinting entirely, and reports a fake system font list. A macOS update that bumps Safari from 14 to 15 introduces all these restrictions at once. The fingerprinting script that previously read a stable canvas hash now gets blocked or gets random data. The device ID resets.

What this means for your fraud pipeline

• A returning fraudster becomes invisible. If a bad actor visits on Firefox with fingerprinting blocked and returns on Brave with randomization enabled, your matcher sees two different visitors.
• Legitimate users can trigger false positives. A user who updates their browser and accepts the new privacy defaults will appear as a new device, potentially breaking session continuity or triggering fraud reviews.
• Tor Browser nearly always defeats fingerprinting. It exposes a consistent fingerprint across all users, which means every Tor visitor looks like the same device. The browser's design makes reliable identification impossible.

These privacy features are not bugs. They are intentional design choices. Your device identification must account for them using probabilistic matching rather than exact hash comparison. The visitor identification API returns a similarity score between 0 and 1, letting you set a confidence threshold that balances catching fraud against misidentifying legitimate users who updated their browser yesterday.

How Device Identification APIs Handle Browser Updates

A browser update invalidates exact fingerprint hashes because signals like canvas rendering, WebGL, and audio context change or get blocked. Exact matching produces a new ID for every updated browser, even if the same person uses the same device. Device identification APIs that rely on a single hash cannot distinguish a legitimate update from a new user or a fraudster swapping browsers.

Probabilistic matching solves this by comparing multiple signals and scoring the similarity between a current request and previously stored device profiles. Instead of requiring an exact bit-for-bit match, the matcher evaluates how many signals align, how stable each signal historically is, and assigns a similarity score between 0 and 1. A score close to 1 indicates strong evidence that the device is the same, even if a few signals shifted after an update. A low score means the device is likely new.

WhorlID is one example of a probabilistic device identification API. It collects roughly 25 signals from the browser (canvas and WebGL rendering, audio context, fonts, hardware concurrency, screen properties, locale) and scores them against devices the project has already seen. The matcher returns a response that includes visitorId, decision (match, new, low, ambiguous), similarity, isReturning, highConfidence, and other fields. The visitorId is scoped per project: the same physical device on two different customers gets two unrelated IDs, and the ID can reset after a hardware change or when anti-fingerprinting software randomizes most signals.

{
  "visitorId": "abc123",
  "decision": "match",
  "similarity": 0.94,
  "isReturning": true,
  "highConfidence": true,
  "isBot": false,
  "botScore": 0.02,
  "threatLevel": "low",
  "requestId": "req_xyz",
  "timestamp": 1710000000
}

Because matching is probabilistic, WhorlID does not guarantee a permanent device identity. Hardened browsers like Tor or Brave with fingerprint randomization can reduce the similarity score so that a returning device appears as new. Residential proxies are not detectable, so the API treats them like any other connection. For fraud teams, probabilistic matching provides a practical ceiling: you can set a confidence threshold that balances catching repeat fraudsters against misidentifying users who updated their browser yesterday. Read the API reference for the full response schema and server-side verification steps.

Practical Steps to Reduce Device ID Churn

Design your fingerprinting strategy around signal volatility. A canvas hash usually survives a Chrome update; a screen resolution does not. Build a signal tier list: persistent signals like WebGL vendor and GPU model, moderately stable signals like canvas fingerprint and audio context, and volatile signals like font list and timezone. Weight the matcher to rely more on persistent signals when scores are close.

Update your fingerprint profiles at regular intervals, not just on first identification. When a returning user scores above 0.8 similarity but not a full match, merge the new signals into their existing profile. This keeps the profile current through incremental browser changes. Treat the decision field (match, new, low, ambiguous) as guidance, not gospel. A "low" decision with 0.65 similarity still indicates the same device with some drifted signals.

Accept that some changes are unavoidable. A major browser version jump or a privacy update that enables fingerprint randomization will reset the ID. Fall back to other risk indicators: login patterns, payment velocity, and proxy evidence from isDatacenter and isProxy. Combine device ID with session behavior to recognize returning fraudsters even when the fingerprint shifts.

Test with real browser updates. Run your integration through Chrome Stable, Beta, and Canary channels, plus Firefox and Safari releases. Measure how many of your test devices return a match decision after each update. Set your confidence threshold on real data, not assumptions. Read the API reference for the full response schema and server-side verification steps.