Browser Fingerprint & Privacy Leak Inspector: Code Examples

Brave Browser Fingerprint Protection

Brave actively randomizes the signals that fingerprinting scripts collect most, offering strong protection without requiring users to switch away from a mainstream browser. Its farbling mechanism, documented in the Brave browser wiki, applies controlled noise to canvas output, WebGL parameters, AudioContext processing, and font enumeration on a per-origin, per-session basis.¹

The randomized values stay consistent within a single session but change between sessions and across different origins, which makes cross-site and cross-session linking impractical without breaking site functionality.² Enabling Standard Shields mode activates farbling for all sites without additional configuration; Aggressive mode extends coverage to additional vectors including first-party trackers.³

Consequently, Brave earns the highest anti-fingerprinting score in independent browser privacy testing suites that measure resistance across dozens of simultaneous signals.⁴ Unlike Tor Browser, Brave routes traffic normally, so standard browsing performance remains unaffected.

Which APIs Brave farbling targets

Farbling applies noise at the API output level rather than blocking APIs entirely, which allows legitimate site functionality to continue while defeating stable fingerprint collection.⁵ The canvas and AudioContext modifications produce values that pass site functionality tests because the noise magnitude is small, enough to change the hash on each new origin but not enough to visually distort canvas rendering or make audio output inaudible.

How Brave farbling works

Consequently, sites that draw charts, run audio processing, or export canvas images continue to work normally. The WebGL renderer modification goes further: rather than returning noisy GPU strings, Brave suppresses the WEBGL_debug_renderer_info extension entirely when Shields are active, returning empty strings instead of the real GPU vendor and renderer.⁶ Building on this, hardware API values like hardwareConcurrency and deviceMemory are replaced with plausible but non-identifying values, reducing the precision with which scripts can estimate your CPU and RAM tier.

The consistency within a session is what preserves usability. A site that reads your canvas hash on page load and again during interaction sees the same farbled value both times, so its logic behaves as expected. You can observe this directly in the fingerprint inspector: reload the same page repeatedly and the farbled rows hold steady, then open a different site or a new session and watch them shift. This balance between stability and variation is the core design choice behind farbling.⁷

Shields levels and per-site configuration

Brave Shields operates at two levels. Standard Shields activates the full farbling suite for all sites by default; this is the setting in a fresh Brave installation and covers the vast majority of fingerprinting vectors without any user configuration. Aggressive Shields extends coverage to some first-party tracking domains that Standard mode allows.⁸ The per-site override panel in the address bar lets you raise or lower the Shields level for individual sites where fingerprinting protection conflicts with required functionality.

What Brave does not solve alone

Yet most sites do not require the high-entropy signals that farbling modifies, so compatibility issues are rare in practice. Brave does not farble every signal; timezone, screen resolution, and browser language remain unmodified because normalizing them would break too many legitimate site features. This means that a determined tracker can still combine the unfarbled signals with behavioral analysis to build a partial profile, even when the high-entropy canvas and WebGL surfaces are fully protected. Understanding which signals Brave modifies and which it leaves intact helps you evaluate whether additional measures like a VPN or a more restrictive browser are needed for your specific threat model.

Where Brave still needs testing

Furthermore, Brave's per-origin randomization means that even if a single site manages to extract a stable hash on one visit, that hash is useless for linking your identity on a different site because the values will differ across origins. The practical implication is that you should test your own setup rather than relying on general claims about Brave's protection level, since the exact signals that change depend on your specific hardware, browser version, and Shields configuration. CapyToolkit makes this testing straightforward by showing each signal row and whether it changes between a default browser and Brave with Shields active.

Testing Brave fingerprint protection with CapyToolkit

Testing the effectiveness of Brave's protections requires comparing a default browser against Brave with Shields active on the same machine. Open CapyToolkit Browser Fingerprint Inspector in Chrome to record your baseline signals, then open it in Brave; the canvas hash, WebGL renderer, audio fingerprint, and hardware concurrency values should all differ. Furthermore, open the tool in a new Brave window to confirm that the canvas hash changes between sessions, demonstrating that farbling prevents stable re-identification.

Rows marked TRACKABLE in the inspector reflect the highest-entropy signals; verifying that those rows show "blocked" or a different value confirms that Brave's protection is active. Conversely, signals like timezone, screen resolution, and language are not farbled; they remain accurate because normalizing them would break too many legitimate site features.

Notes

Brave farbling affects these specific APIs. HTMLCanvasElement.toDataURL() and toBlob() receive per-site random pixel noise consistent within a session but different across origins. navigator.hardwareConcurrency returns a random value from the set {2, 4, 8} regardless of actual CPU core count when Shields are active. navigator.deviceMemory reports 8 regardless of actual device RAM. The WEBGL_debug_renderer_info extension returns empty strings for UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL. OfflineAudioContext oscillator output receives per-site noise injected into the frequency response values. navigator.plugins returns an empty array. Font probing via CanvasRenderingContext2D.measureText() returns results from a randomized font subset.

Shields levels: Standard blocks third-party trackers and activates farbling. Aggressive additionally blocks some first-party trackers. Per-site Shields settings are accessible via the Brave address bar and take effect immediately without a restart.

Examples

Chrome:  c84efb8e3a92d710fbcae2f5b0078efb  (stable across page loads)
Brave:   7a1df3c94b21e6f902b3... (changes per origin and session)

Chrome:  `navigator.hardwareConcurrency` → 12  (real CPU core count)
Brave:   `navigator.hardwareConcurrency` → 8   (farbled to nearest set value)

Chrome:  `UNMASKED_RENDERER_WEBGL` → "ANGLE (NVIDIA GeForce RTX 4070...)"
Brave:   `UNMASKED_RENDERER_WEBGL` → ""  (extension blocked)

Try in the tool

Firefox Fingerprinting Protection

When you want configurable anti-fingerprinting in a mainstream browser, Firefox resistFingerprinting is one of the most transparent options. Enabling privacy.resistFingerprinting in about:config activates a suite of browser-level protections developed through the Firefox Tor Uplift project, which ported Tor Browser's anonymization techniques into mainstream Firefox.¹

With RFP enabled, screen dimensions are rounded to the nearest 200 pixels with a minimum of 1000x900, timezone is frozen to UTC, navigator.hardwareConcurrency is capped at 2, navigator.oscpu returns a generic string, and several WebGL parameters are masked.² Firefox 120 extended partial RFP protections to the Strict mode in Enhanced Tracking Protection, providing a subset of these protections without the full about:config change.³

Consequently, Firefox offers a gradient of fingerprinting protection from zero through partial to maximum without requiring any extensions or external tools. Building on this, RFP is the most transparent implementation in any mainstream browser because its specific modifications are publicly documented in the Firefox source code.

Enabling privacy.resistFingerprinting and what it changes

Setting privacy.resistFingerprinting to true in Firefox about:config activates browser-level interception for a defined set of fingerprinting APIs, and the change takes effect immediately for all new page loads without requiring a browser restart. The most visible change is screen dimension rounding: a 1920x1080 monitor reports screen.width 1000 and screen.height 900, the minimum rounded value, which effectively masks the actual display resolution from any script that reads the screen object.⁴ The timezone freeze to UTC affects all time-related computations, including Date.prototype.getTime() comparisons that depend on local offset and Intl.DateTimeFormat outputs, making every Firefox RFP user appear to be in the same global timezone.⁵

What privacy.resistFingerprinting changes

navigator.hardwareConcurrency frozen at 2 prevents CPU tier classification.⁶ Consequently, these frozen values match those of every other Firefox RFP user on every other machine, making the modified signals identical across a large population of Firefox users globally. Building on this, the canvas modification intercepts toDataURL() and injects a session-consistent random perturbation to the pixel buffer before returning it. This approach differs from Brave's per-site randomization: Firefox RFP uses the same perturbation within a session regardless of which site is queried.

The transparency is what makes RFP different from proprietary approaches. Every frozen value and rounding rule is visible in the Firefox source, so you can inspect exactly which signals change rather than trusting a vendor summary. You can confirm the active protections in the fingerprint inspector, where the timezone row moves to UTC and hardwareConcurrency drops to 2 the moment RFP takes effect on a new page load.

What RFP leaves exposed

Despite its broad coverage, privacy.resistFingerprinting leaves several signals accessible to fingerprinting scripts. The audio fingerprint is partially reduced but not fully randomized; OfflineAudioContext processing is modified, but the degree of modification is less aggressive than Brave's per-site noise injection. The canvas hash is modified rather than fully randomized per site, which means that within a single Firefox RFP session, the same canvas hash is returned to every site, different from Chrome but consistent across origins within the session.

When Firefox protection is worth the trade-off

The installed font set receives some restriction but not the comprehensive subset-limiting that Brave applies. Browser language and locale are not frozen, leaving Accept-Language and Intl.DateTimeFormat locale data exposed. Consequently, a Firefox RFP user is distinguishable from a standard Chrome user but may not be fully unlinkable across sites within a single session if multiple sites receive the same session-consistent canvas hash.⁷ Building on this, combining Firefox RFP with uBlock Origin in strict mode and blocking additional third-party JavaScript addresses the remaining gaps more completely.

Firefox with uBlock Origin in strict mode

The most practical combined Firefox configuration for fingerprinting resistance pairs privacy.resistFingerprinting with uBlock Origin set to medium or hard blocking mode. uBlock Origin in hard mode blocks third-party scripts by default, which prevents most fingerprinting JavaScript from executing at all, the most effective mitigation because a blocked script cannot collect any signals regardless of what Firefox exposes. RFP addresses the case where fingerprinting code executes as first-party or slips through uBlock's domain filters.

Consequently, the combination defends at two independent layers that address different parts of the fingerprinting pipeline: uBlock Origin prevents most fingerprinting JavaScript from executing at all by blocking the third-party domains that serve the tracking scripts, and RFP limits what any successfully-executed script can collect from the browser's hardware and configuration APIs even when the script runs as first-party code that uBlock cannot block by domain alone.

Why two layers matter

Furthermore, Firefox's container tabs feature allows session isolation per site, which prevents the same-session canvas hash consistency problem that standard Firefox RFP creates.⁸ Building on this, this combined approach provides stronger fingerprinting protection than Brave's default configuration in the specific scenario where a fingerprinting script executes as first-party JavaScript on a site, because RFP's canvas modification plus uBlock Origin's script blocking creates two independent barriers.

Notes

privacy.resistFingerprinting effects: screen.width and screen.height are rounded to the nearest 200px multiple (minimum 1000x900), regardless of actual monitor resolution. Intl.DateTimeFormat().resolvedOptions().timeZone returns 'UTC' and Date.prototype.getTimezoneOffset() returns 0. navigator.hardwareConcurrency returns 2. navigator.oscpu returns 'Intel Mac OS X 10.15' (a historical frozen value). navigator.deviceMemory is undefined when RFP is active. Canvas APIs return modified pixel data to prevent canvas fingerprinting. AudioContext frequency response data is modified to prevent audio fingerprinting. navigator.userAgent returns a spoofed Firefox/macOS string. The WEBGL_debug_renderer_info extension is suppressed.

Firefox 120+ Strict Enhanced Tracking Protection enables a subset: timezone and some canvas protections, but not all RFP behaviors. Setting location: about:config, preference name: privacy.resistFingerprinting, type: Boolean, default: false.

### What changes are visible in CapyToolkit

After enabling RFP, CapyToolkit should show the timezone row changing to UTC, hardwareConcurrency moving to 2, and canvas/audio values becoming modified. These visible changes make it easier to confirm that the setting is active before you rely on it for sensitive browsing.

Examples

Default Firefox:  `screen.width` → 1920 (real monitor width)
Firefox RFP on:   `screen.width` → 1000 (rounded to minimum 1000x900)

Default Firefox:  `navigator.hardwareConcurrency` → 12 (real CPU core count)
Firefox RFP on:   `navigator.hardwareConcurrency` → 2  (frozen value)

Try in the tool

Tor Browser Fingerprint Protection

For anonymity-focused browsing, Tor Browser makes all users appear to share the same fingerprint. Rather than randomizing signals per site or masking hardware values, Tor Browser's approach is anonymity through uniformity: every Tor Browser user on the same major version produces the same canvas hash, the same User-Agent string, the same screen dimensions, and the same font set.¹ This design is deliberate. When one person's Tor Browser fingerprint looks different from another's, that difference becomes a tracking signal.

By making all fingerprints identical, Tor Browser eliminates per-user identification within the Tor user population. Consequently, tracking a specific Tor Browser user requires behavioral analysis or network-level deanonymization rather than passive fingerprinting. Building on this, Tor Browser's Security Levels, Standard, Safer, and Safest, progressively disable more browser features, with Safest disabling JavaScript entirely, which eliminates the entire JavaScript-accessible fingerprinting surface at the cost of compatibility with most modern websites.²

How Tor achieves a uniform fingerprint

Tor Browser's uniformity is enforced by a set of patches applied on top of Firefox ESR that normalize the browser environment across all Tor users on the same major version. The canvas API intercept returns a blank result rather than real rendered pixel data, making every Tor Browser installation return the same canvas output regardless of the underlying GPU and font configuration.³ The User-Agent string is set to a fixed value shared by all Tor Browser users, reporting Windows and a specific Firefox ESR version regardless of the actual OS.

How Tor Browser normalizes identity

Letterboxing constrains the inner viewport to multiples of 200x100 pixels, preventing window size from becoming a fingerprinting signal.⁴ Consequently, passive fingerprinting scripts that collect canvas, User-Agent, screen size, and WebGL data receive the same values from every Tor Browser user, making individual identification through these signals structurally impossible. Building on this, the font set is limited to a Tor-specific standard list, preventing font probe detection from revealing the actual installed fonts on the host machine.

The letterboxing bars you see around the page are the visible cost of this uniformity. The outer window can be any size, but Tor clips the usable area to a 200x100 grid so the reported dimensions stay fixed. You can watch the effect in the fingerprint inspector: even after you drag the Tor window to a different size, the screen width and height rows report the same rounded values as every other Tor user on that version.

Security level trade-offs

Standard security level enables JavaScript on all sites, activates the fingerprinting-resistance suite, and provides the strongest compatibility with modern websites. Safer level disables JavaScript on HTTP-only (non-HTTPS) sites and blocks additional high-risk browser features. Safest level disables JavaScript entirely on all sites, which eliminates the entire JavaScript fingerprinting surface because fingerprinting scripts cannot execute at all.⁵

Why Tor is not a normal browser

Yet Safest mode breaks most modern websites, since JavaScript is required for navigation, forms, and content loading on virtually all contemporary sites. Consequently, users who need both anonymity and site compatibility typically use Standard or Safer mode, relying on Tor Browser's passive fingerprinting protections rather than JavaScript blocking. Building on this, the Security Level selector is accessible through the shield icon in the Tor Browser toolbar, and changes take effect immediately without requiring a browser restart.

When Tor's anonymity model is and is not sufficient

Tor Browser's fingerprinting resistance is designed to be effective only when the browser is used exactly as distributed, without any user modifications that distinguish one installation from another. Adding browser extensions to Tor Browser, changing the default font size, resizing the window beyond the letterboxed boundaries that Tor enforces, or logging into personal accounts all destroy the uniformity that is the entire foundation of Tor's anti-fingerprinting model. Each modification makes one Tor user's environment distinct from every other Tor user, creating a unique fingerprinting surface within a population that is supposed to be completely indistinguishable.

Consequently, the Tor Project explicitly recommends against adding extensions and against maximizing the browser window to sizes beyond what Tor controls, because even a single customization such as installing a font extension or resizing the viewport breaks the carefully maintained uniformity that makes every Tor Browser installation indistinguishable from every other one in the global user population.⁶

Where fingerprinting resistance stops

Furthermore, Tor Browser's network anonymization routes traffic through three relays (guard, middle, and exit), providing transport-layer anonymity that supplements the fingerprint uniformity.⁷ Yet Tor's anonymity model does not protect against deanonymization attacks that combine fingerprint uniformity with behavioral patterns; the timing of requests, the sequence of sites visited, or the content of form inputs can narrow a user's identity even when the fingerprint itself is uniform.⁸

Notes

Tor Browser technical details: based on Firefox ESR with specific patches maintained by the Tor Project. Security Level Standard: JavaScript enabled on all sites; canvas API returns a blank or null result rather than real rendered output; fingerprinting-resistant values from Firefox RFP are active. Security Level Safer: JavaScript disabled on HTTP-only sites; additional APIs blocked; canvas blocked more aggressively. Security Level Safest: JavaScript disabled on all sites; maximum API blocking.

Letterboxing: the browser viewport is rounded to multiples of 200x100 pixels to prevent window size fingerprinting, the outer window may be larger, but the inner viewport is always a multiple of 200x100. Font set: limited to a standard Tor Browser-specific font list, preventing font probe detection of additional installed fonts. User-Agent: reports the same Firefox string as all other Tor Browser users on the same major version. WebGL: disabled at Safer security level by default.

Examples

Chrome:       canvas hash = c84efb8e3a92d710fbcae2f5b0078efb
Tor Browser:  canvas hash = [null / blank / consistent empty value]

Click the shield icon in the Tor Browser toolbar.
Select Standard, Safer, or Safest.
The change takes effect immediately without restart.

Try in the tool

Chrome Fingerprint Exposure

Among mainstream desktop browsers, Chrome exposes the broadest default fingerprinting surface. Chrome has no built-in fingerprinting protection and exposes most signals by default. navigator.hardwareConcurrency returns the real CPU core count, navigator.deviceMemory returns the real RAM class, screen.width and screen.height report accurate display dimensions, and the WEBGL_debug_renderer_info extension returns the full GPU vendor and renderer strings.

The canvas API returns real rendered pixel data, enabling stable hash collection. UA Reduction, shipped in Chrome 107, froze the minor version number to 0.0.0.0, reducing the entropy of the User-Agent string component, but this change did not address canvas, WebGL, audio, or hardware API signals, which remain the primary fingerprinting surface.¹

Consequently, Chrome provides the largest exposed fingerprint surface of any mainstream browser by default. Building on this, Google's Privacy Sandbox initiative focuses on replacing third-party cookies with cohort-based advertising APIs but does not restrict JavaScript fingerprinting signals, leaving Chrome's hardware exposure profile unchanged.²

What Chrome exposes by default

Chrome's default configuration exposes the full fingerprinting signal set without any attenuation. The canvas API produces hardware-specific rendering that generates a stable hash unique to each GPU, driver, and font configuration. The WEBGL_debug_renderer_info extension is available by default, returning the GPU model and driver information that directly identifies the graphics hardware tier. OfflineAudioContext completes fully and returns real audio processing results that reflect CPU floating-point behavior.

Why Chrome exposes a detailed profile

navigator.hardwareConcurrency and navigator.deviceMemory both report real hardware values without any capping or randomization. Consequently, a Chrome user without additional extensions or privacy software provides one of the most complete passive fingerprint profiles available in any mainstream browser.³ Building on this, Chrome's widespread adoption means that Chrome fingerprints are the most common profile type in fingerprinting databases, which paradoxically reduces some entropy by making common Chrome configurations less distinctive. Yet the hardware variation within Chrome's user base is large enough that specific GPU and CPU combinations remain highly unique.

The absence of any built-in protection is the defining characteristic here. Chrome ships with every signal exposed and offers no native setting to attenuate it, so the protection burden falls entirely on the user. You can see the full exposed set in the fingerprint inspector, where hardwareConcurrency, deviceMemory, and the WebGL renderer all report their real values on a default Chrome install with no modifications applied.

UA Reduction and its actual entropy impact

Chrome 107's UA Reduction change froze the minor, build, and patch version components of the User-Agent string to 0.0.0 for all Chrome installations worldwide, which means every Chrome 107 user now reports an identical version string regardless of their actual build number.⁴ Previously, the full Chrome build number was included in every HTTP request and JavaScript API call, which allowed fingerprinting scripts to identify even minor Chrome updates and distinguish between users on different release channels. After UA Reduction, all Chrome users on major version 107 report "107.0.0.0" regardless of their specific build, eliminating the per-build tracking vector from the passive UA string.

How to compare Chrome with privacy browsers

The practical entropy reduction from this change is modest; the UA string was already one of the lower-entropy components compared to canvas and WebGL. Furthermore, the User-Agent Client Hints API provides a mechanism for servers to request the full version string via Accept-CH, which means UA Reduction primarily affects passive collection rather than active collection.⁵ Consequently, the fingerprinting signals that drive the highest entropy, canvas hash, WebGL renderer, and audio fingerprint, are unchanged by UA Reduction. Building on this, Chrome's stated rationale was to reduce UA entropy gradually and nudge sites toward the structured Client Hints API.

Extension options for Chrome users

Chrome users who want any fingerprinting protection must rely entirely on browser extensions, since Chrome itself provides no built-in anti-fingerprinting features whatsoever. uBlock Origin in medium or hard blocking mode prevents third-party fingerprinting scripts from executing, which is the most effective approach when the scripts are loaded from known third-party domains that uBlock's filter lists already cover. CanvasBlocker adds random noise to HTMLCanvasElement.toDataURL() and toBlob() exports, changing the canvas hash on each page load so that the same machine produces a different hash every time.⁶

Yet no Chrome extension can fully replicate Brave's farbling depth because Chrome's extension API does not allow the same low-level API interception that Brave's built-in native implementation uses to modify values before JavaScript ever sees them, which means extension-based protections always operate one layer above the browser engine and can be detected by scripts that check for consistent API behavior across multiple call sites.⁷

Why extensions are only partial

Consequently, extension-based canvas blocking is detectable: a canvas hash that changes on every access is itself a fingerprinting signal indicating the presence of a spoofing extension. Furthermore, Chrome extension permissions have been progressively restricted through Manifest V3, which limits the ability of privacy extensions to intercept API calls before they return data to scripts.⁸ Building on this, the most complete fingerprinting protection available for Chrome users who cannot switch browsers remains the combination of uBlock Origin in strict mode plus CanvasBlocker.

Notes

Chrome fingerprinting exposure: navigator.hardwareConcurrency returns the real logical CPU core count. navigator.deviceMemory returns the real device RAM rounded to {0.25, 0.5, 1, 2, 4, 8}. screen.width and screen.height report real CSS pixel dimensions. window.devicePixelRatio reports the real display scaling factor. WEBGL_debug_renderer_info is available; UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL return real GPU vendor and renderer strings. HTMLCanvasElement.toDataURL() returns real GPU-rendered pixel data. OfflineAudioContext.startRendering() returns real audio processing results.

navigator.userAgent uses reduced form (minor version frozen to 0.0.0) since Chrome 107. Sec-CH-UA, Sec-CH-UA-Mobile, and Sec-CH-UA-Platform are sent by default on all requests. Chrome on Android: same exposure profile as desktop Chrome. Chrome on iOS: uses WebKit rendering engine, not Blink; canvas hash and WebGL behavior differ from desktop Chrome.

Examples

Before (Chrome 106): Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.5249.119 Safari/537.36
After (Chrome 107+):  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

Chrome:  `navigator.hardwareConcurrency` → 12  (real value)
Brave:   `navigator.hardwareConcurrency` → 8   (farbled)

Try in the tool

Safari Fingerprint Protection

Across Safari versions, Apple has taken the most consistent cross-version anti-fingerprinting policy of any mainstream browser. Apple blocked the WEBGL_debug_renderer_info extension in Safari 12, making WebGL renderer strings unavailable since 2018.¹ WebRTC on iOS Safari has used mDNS token substitution for local IP addresses since iOS 14, preventing LAN IP exposure.² iOS 26 introduced Advanced Fingerprinting and Tracking Protection (AFP) as a default-on feature, extending protection to canvas rendering output, audio processing, and font access.³ Intelligent Tracking Prevention (ITP), active since Safari 11, partitions cookies and localStorage across sites.⁴ Consequently, Safari's anti-fingerprinting posture has expanded with each major release rather than being delivered as a single configuration option.

Building on this, Safari on iOS and Safari on macOS differ in their protection depth; iOS AFP is enabled by default, while macOS Safari 26 requires the user to enable it in Preferences, creating a difference between the iOS and macOS fingerprint profiles even on the same major Safari version.⁵

Safari's anti-fingerprinting history from Safari 12 to AFP in iOS 26

Safari began restricting fingerprinting-relevant APIs earlier than any other mainstream browser. The WEBGL_debug_renderer_info block in Safari 12 (2018) removed WebGL GPU identification from all Safari versions, years before Brave's farbling or Chrome's UA Reduction.¹ Intelligent Tracking Prevention, introduced in Safari 11, applied cross-site cookie partitioning that reduced cookie-based tracking while laying the technical groundwork for further isolation.⁴

What Safari limits by default

Safari 14 introduced privacy report indicators showing blocked cross-site trackers. iOS 14 changed WebRTC ICE candidate generation to use mDNS tokens instead of real LAN IPs, addressing the WebRTC IP leak without disabling WebRTC functionality.² Consequently, each Safari major release has added an anti-fingerprinting or anti-tracking capability, creating an incremental posture rather than a single configurable setting. Building on this, iOS 26 AFP represents the most significant expansion of Safari's anti-fingerprinting coverage, targeting the canvas, audio, and font signals that previous Safari versions left exposed.

The WebRTC change is a good example of Apple's pattern: block the leak without breaking the feature. By substituting an mDNS token for the real LAN address, Safari hides the local IP that fingerprinting scripts used to read while keeping video and voice calls working. You can verify the effect in the fingerprint inspector, which shows an mDNS token such as a3f4b5c6.local instead of a private network address on iOS Safari.³

iOS 26 AFP in practice

AFP activates automatically after upgrading to iOS 26 and applies to all Safari browsing including private windows. In Settings > Safari > Privacy, Advanced Fingerprinting and Tracking Protection appears as a toggle that is on by default.⁶ When AFP is active, canvas rendering output is modified before returning to scripts, WebGL rendering output undergoes normalization, audio processing results are altered to reduce DAC-specific variation, and font access is limited to a common subset.

How AFP changes Safari fingerprinting

Consequently, CapyToolkit Browser Fingerprint Inspector will show different canvas hash values and a reduced font list on iOS 26 compared to earlier iOS versions on the same device.⁷ Building on this, AFP's normalization approach means the canvas hash may be consistent across sessions for a given user, just different from the pre-AFP hash, whereas Brave's farbling changes the hash across sessions. Users checking their fingerprint after upgrading should run the inspector twice to confirm whether the canvas hash is session-stable (AFP normalization) or session-variable (Brave-style farbling).

Safari on iOS vs. macOS fingerprint differences

iOS and macOS Safari produce structurally different fingerprint profiles even when running the exact same Safari major version number, which surprises many users who expect consistency across Apple platforms. On iOS, AFP is default-on for all users after upgrading to iOS 26, navigator.deviceMemory is undefined because Apple never implemented the API, WebRTC uses mDNS token substitution for local IP addresses, and canvas rendering output is modified before scripts can read the pixel buffer. On macOS Safari 26, AFP requires manual activation in Safari preferences, navigator.hardwareConcurrency returns the real Mac CPU core count, and the canvas hash reflects the full GPU-rendered value if the user has not opted into AFP protection.⁸

Furthermore, the rendering pipeline differs in ways that affect the canvas hash and other rendering-based signals: iOS Safari uses Metal and WebKit on ARM hardware with a GPU that shares memory with the CPU, while macOS Safari uses Metal and WebKit on either Apple Silicon or Intel, producing different floating-point rounding behavior in the rendering pipeline that fingerprinting scripts can detect even when the browser version number is identical.

Why iOS and macOS should be tested separately

Consequently, a fingerprinting script that collects signals from both an iOS and macOS Safari browser on the same Apple account cannot link them through passive signals alone, since the hardware architecture, AFP state, and available APIs are different. Building on this, developers testing fingerprinting behavior across Apple platforms should test iOS and macOS separately rather than assuming one represents the other.

Notes

Safari fingerprinting-relevant API behaviors: WEBGL_debug_renderer_info: blocked since Safari 12; getExtension('WEBGL_debug_renderer_info') returns null; UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL return empty strings. WebRTC local IP: since iOS 14, ICE host candidates use mDNS tokens (e.g., a3f4b5c6.local) instead of real LAN IPs; STUN-reflexive candidates still expose the public IP. navigator.deviceMemory: not implemented; returns undefined in all Safari versions.

navigator.hardwareConcurrency: returns real core count on macOS Safari; iOS Safari returns a value matching the device class. iOS 26 AFP (default-on): canvas output modified, WebGL rendering output modified, audio processing normalized, font access restricted to common subset. macOS Safari 26 AFP: available in Safari Settings > Privacy; requires manual enabling. ITP: partitions localStorage, SessionStorage, and cookies across sites; does not address hardware fingerprinting.

Examples

Chrome (macOS):   `UNMASKED_RENDERER_WEBGL` → "Apple M2"
Safari (macOS):   `UNMASKED_RENDERER_WEBGL` → "" (extension blocked since Safari 12)

Settings > Safari > Privacy
Advanced Fingerprinting and Tracking Protection: [toggle, default: on]

Try in the tool

FingerprintJS Library

For developers evaluating browser-based recognition, FingerprintJS is the most widely used open-source browser fingerprinting library. Published on npm as @fingerprintjs/fingerprintjs,¹ the library provides a single API: FingerprintJS.load() returns a Promise that resolves to an agent object, and agent.get() returns a result containing visitorId and confidence.² visitorId is a stable hash derived from 40+ browser signals including canvas, WebGL, audio, screen, fonts, hardware, and User-Agent.³

confidence is a score from 0 to 1 indicating how reliably the visitorId identifies this specific browser across sessions. The open-source library (v5, MIT licensed; v4 used the Business Source License) runs entirely client-side.⁴⁵ FingerprintJS Pro extends the same concept with server-side signal collection, TLS fingerprint, HTTP/2 session parameters, and bot detection logic, returning a higher-confidence requestId verified server-side.⁶ Consequently, FingerprintJS provides the reference implementation for how production fingerprinting systems combine dozens of signals into a single stable identifier used for fraud prevention and authentication.

Using the open-source library

The FingerprintJS open-source library initializes with a single async call. Calling FingerprintJS.load() returns a Promise that resolves to an agent, a lightweight object with a single method, get(). Calling agent.get() triggers signal collection: the library runs canvas rendering, WebGL parameter queries, OfflineAudioContext processing, font probing, and hardware API reads, then combines the results into a deterministic hash.

How FingerprintJS creates an identifier

The resulting visitorId is a hex string that identifies the browser-device combination. confidence.score reflects how many high-entropy signals were successfully collected; if canvas and WebGL are blocked by the browser, the score drops below 0.7 because the hash is based on fewer distinctive inputs.³ Consequently, visitorId is useful for fraud prevention, identifying the same browser making multiple suspicious requests, and for passwordless device recognition. Building on this, the library is appropriate for legitimate authentication and fraud use cases; it identifies a browser-device combination, not a specific person, which is an important distinction for GDPR and similar privacy law compliance.

The stability is the feature that makes the identifier useful in production. Because the hash depends only on the signal set, the same machine returns the same visitorId every time it visits, which is what lets a site recognize a returning browser without a cookie. You can watch this in action by running the FingerprintJS example in the fingerprint inspector, where the visitorId stays fixed across page reloads until a protection like Brave Shields changes the underlying canvas input.

FingerprintJS Pro vs. open source

FingerprintJS Pro adds server-side signal collection that cannot be replicated by client-side JavaScript alone. The Pro library sends collected browser signals to Fingerprint Inc.'s servers, which analyze TLS fingerprint characteristics, HTTP/2 session headers, IP geolocation, and bot detection signals in addition to the JavaScript-accessible browser APIs.⁶ The server returns a requestId, a cryptographically verified identifier that the application server can validate against the Fingerprint API to confirm authenticity.

How to use it responsibly

Consequently, Pro is substantially more robust against spoofing than the open-source library, because the server-side signals cannot be modified by JavaScript injection or extension-based interception. Yet the trade-off is that user data is sent to a third-party service, which requires disclosure in privacy notices and data processing agreements under GDPR.⁷ Building on this, for applications where fraud risk is high, account takeovers, payment fraud, and credential stuffing, Pro's server-side verification provides a meaningful improvement in reliability over the client-side-only hash.

Interpreting visitorId and confidence score

The visitorId is a deterministic hash of the browser's signal set; the same browser on the same device will produce the same visitorId across page loads and sessions as long as the underlying signals do not change. Significant browser events that change visitorId include: GPU driver updates that alter the canvas hash, upgrading to iOS 26 with AFP enabled (which modifies canvas output), and enabling Brave Shields (which farbles canvas, WebGL, and audio).

confidence.score provides a reliability estimate for this stability. A score of 0.9 or above indicates that high-entropy signals like canvas and WebGL were available and consistent.² A score below 0.5 indicates that key signals were blocked or returned unstable values, for example, if the user enabled Firefox RFP between visits or switched browsers.

How to avoid over-trusting the score

Consequently, applications that use visitorId for authentication should pair it with a fallback mechanism for cases where the confidence score indicates instability. Building on this, visitorId changes when the user clears browser storage are expected; the library is designed to be resilient to storage clearing through hardware signal stability. However, a high confidence score does not guarantee that the visitorId identifies a specific person; it only confirms that the browser-device combination is stable. Applications should treat visitorId as one signal within a broader risk assessment rather than as a sole authentication factor, since the same score can represent either a genuinely unique browser or a common configuration shared by thousands of users.

Notes

FingerprintJS API reference: npm install @fingerprintjs/fingerprintjs. FingerprintJS.load({ apiKey?: string }): returns Promise. agent.get({ extendedResult?: boolean }): returns Promise. GetResult: { visitorId: string; confidence: { score: number; comment?: string }; components?: Record }. visitorId: a deterministic hash of collected signals, stable for the same browser-device combination across sessions.

confidence.score: a number from 0 to 1; 1.0 indicates high confidence that visitorId is stable; below 0.5 indicates instability due to blocked signals. FingerprintJS Pro: requires an API key from fingerprint.com; extends the open-source library with server-side signals (TLS fingerprint, HTTP/2 headers, IP geolocation, incognito detection). Returns requestId (a server-verified identifier) in addition to visitorId. The open-source library is MIT licensed. FingerprintJS Pro is a commercial product requiring a subscription. Both variants collect canvas, WebGL, audio, and hardware signals.

Examples

import FingerprintJS from '@fingerprintjs/fingerprintjs';

const fp = await `FingerprintJS.load()`;
const result = await fp.get();

console.log(result.visitorId);         // 'a3f4b5c6d7e8f9a0...'
console.log(result.confidence.score);  // 0.92

Without Brave Shields:  visitorId = a3f4b5c6... (stable across loads)
With Brave Shields:     visitorId = f9e8d7c6... (different due to farbled canvas)

Try in the tool