Safari Fingerprinting on iPhone and Mac

Safari Fingerprinting on iPhone and Mac

Safari's fingerprint depends on which Apple device runs it. On an iPhone, every browser app uses WebKit, so Chrome, Firefox and Safari share one engine and one set of protections. On a Mac, that rule does not apply: Chrome and Firefox bring their own Blink and Gecko engines, and Safari's protections cover only Safari. The font list differs too, since a Mac can install fonts system-wide through Font Book while an iPhone keeps a fixed factory set.

Two protections stack on Apple's engine. WebKit has returned an empty WebGL renderer string since Safari 12, and Advanced Fingerprinting Protection, on by default since iOS 26, modifies canvas, WebGL, audio and font signals. Neither touches hardware or locale values such as CPU core count, screen size, time zone or language, so those rows in the inspector still report real values. The sections below cover the iPhone, the Mac and the iOS 26 change in turn, with what each protection hides and what it leaves visible.

Browser Fingerprinting on iPhone (Safari)

This iPhone runs on WebKit, the engine every browser app on iOS is required to use, so the fingerprinting surface the inspector above measures here is really Safari's surface no matter which app icon you tapped to get here. Two separate defenses stack on top of that shared engine: the WebGL renderer string has returned an empty value since Safari 12, years before any dedicated anti-fingerprinting feature existed, and Apple's Advanced Fingerprinting Protection (AFP), on by default since iOS 26, separately modifies canvas rendering, WebGL output, audio processing, and font access.¹ Neither protection touches hardware or locale signals, so a handful of rows in the scan above still report values as real as they would on a browser with no defenses at all.

Specifications

Two different protections are stacked on this iPhone, and they cover different signals

WebKit has returned an empty string from the WebGL renderer query since Safari 12,² a restriction that predates Advanced Fingerprinting Protection by years and has nothing to do with the iOS 26 rollout. AFP itself is newer and narrower in a different way: it modifies canvas rendering output, WebGL rendering, OfflineAudioContext processing, and font access, reducing the uniqueness of each without hiding that a scan ran at all. Reading the rows on this page as one undifferentiated "protected" block misses that two unrelated mechanisms, one old and one new, are doing the actual work.

The WebGL renderer row is empty here for a reason that predates AFP

Calling getExtension('WEBGL_debug_renderer_info') and reading UNMASKED_RENDERER_WEBGL on this iPhone returns an empty string rather than a GPU model name, a restriction Safari has applied since version 12.² That stands in contrast to Android Chrome, where the same query on a Galaxy phone returns a full string like "Adreno (TM) 750" identifying the exact chipset. The row will read blank here whether or not AFP is active, because the WebGL renderer restriction and AFP are two separate protections that happen to affect the same API surface for different reasons.

Because the renderer string has been unavailable for so long, most fingerprinting scripts targeting iOS Safari never relied on it in the first place; the practical effect of the block is closer to background noise than a recent policy shift. It is worth knowing regardless, since a reader comparing this scan against a friend's Android phone will see a populated WebGL row on the Android side and a blank one here for a reason that has nothing to do with either device's actual privacy settings.

What AFP changes here versus what stays real

On this iPhone, AFP means the canvas hash, the WebGL rendering readout, and the audio fingerprint rows will differ from a capture taken before iOS 26, and the font-detection row is limited to a common subset rather than every font Safari can technically render.¹ navigator.hardwareConcurrency, screen.width and screen.height, window.devicePixelRatio, and the timezone and language rows are not part of what AFP modifies, so those continue to report this iPhone's real values every time the scan runs.

That split matters for reading the entropy score above. A drop in the CANVAS, WEBGL, and AUDIO groups after an iOS update reflects AFP doing its job; a row in IDENTITY or the hardware group staying exactly the same across scans is not a sign the protection missed something, it is a signal AFP was never designed to touch in the first place.

Why every app on this iPhone runs the identical protections

Apple's App Store Review Guidelines state that apps which browse the web on iOS must use the WebKit rendering engine and WebKit JavaScript, a requirement numbered 2.5.6 that has applied since the App Store launched.³ In practice that means Chrome, Firefox, Edge, and every other browser you can install on this iPhone wraps WebKit in its own interface rather than shipping Blink or Gecko the way those same browsers do on a laptop. Switching apps here changes the toolbar, the extensions available, and which account syncs your history, but it does not change which engine renders the page or which fingerprinting defenses apply underneath it.

The layout viewport stays fixed even when you pinch to zoom

iOS separates the layout viewport, the width Safari uses to lay a page out, from the visual viewport, which is what you actually see after zooming. Apple's own viewport documentation describes pinch-to-zoom as changing the visual viewport's scale while leaving the layout viewport's width unchanged, and window.devicePixelRatio stays fixed at the same value throughout that gesture regardless of how far in you have zoomed.⁴⁵ A script reading either property back gets the same number before, during, and after a pinch-zoom gesture on this device.

That stability is exactly why devicePixelRatio and the layout viewport width sit among the real, unmodified values discussed above: they behave like fixed hardware constants tied to the physical panel rather than something a reader's own zooming or resizing habits could change moment to moment, which is also what makes them a genuinely useful, repeatable match signal for this specific iPhone model rather than noise AFP would need to touch.

Browser Fingerprinting on MacBook (Safari)

Apple's rule requiring every iOS browser app to run on WebKit does not reach macOS.¹ Chrome and Firefox installed on this MacBook run their own Blink and Gecko engines rather than wrapping Safari's WebKit the way every browser on an iPhone must, so the browser you pick here genuinely changes which engine renders the page and which anti-fingerprinting behavior, if any, applies to it. This machine also lets you install custom fonts system-wide through Font Book, something the fixed factory font set on a phone rarely sees.

Specifications

Why the browser you pick on this Mac changes more than it does on an iPhone

Apple's App Store Review Guidelines require apps that browse the web on iOS to use the WebKit rendering engine, a rule numbered 2.5.6.¹ That requirement governs iOS App Store distribution specifically; it has no equivalent for macOS. Chrome and Firefox installed on this MacBook ship their native Blink and Gecko engines rather than wrapping WebKit, which means picking a browser here is a genuinely different decision than picking one on a phone, where every app icon leads back to the same underlying engine.

Safari's protections are Safari-specific on this machine

Safari on macOS offers an "Advanced Tracking and Fingerprinting Protection" toggle in Safari > Settings > Advanced, which layers noise and normalization onto canvas, WebGL, and audio readouts when enabled.² That protection lives inside WebKit itself, so it only ever covers browsing sessions that actually run through Safari on this machine. Opening the same page in Chrome on this identical MacBook leaves you on Blink with none of it, a fundamentally different situation from an iPhone where every browser app inherits the same engine-level defenses automatically.

A fresh Chrome profile on this Mac starts from a genuinely different baseline

Because Chrome and Safari on this MacBook run different rendering engines rather than the same engine wrapped in different interfaces, a script comparing canvas hashes between the two would see output shaped by two distinct rendering pipelines, not just two different browser UIs sitting on identical internals. That is a deeper split than Samsung Internet versus Chrome on the same Galaxy phone, where CapyToolkit's own Android guide shows both browsers query identical hardware signal APIs even though their canvas hashes differ; here, switching browsers can mean switching engines outright.

Why the font list on this Mac can grow well past a phone's fixed set

Font Book lets you install fonts system-wide on this MacBook, either for your own account or for every user on the machine.³ Font enumeration, one of the techniques browser fingerprinting relies on, reads from the operating system's installed font list rather than anything scoped to a single browser, so anything added through Font Book becomes visible to a probe running in Safari, Chrome, or Firefox alike on this same machine.

An installed font library becomes a shared fingerprinting signal across every browser here

Installing a design agency's licensed typefaces or a Creative Cloud font library through Font Book adds entries a canvas-based font probe can detect in any browser you open afterward, since the detection happens at the OS level rather than inside a sandboxed per-app font set.⁴ A phone's fixed, rarely-customized factory font set gives a fingerprinting script much less to work with by comparison; a MacBook whose owner has installed a personal or professional font library over the years hands over a list that reflects real software choices, not just the operating system's defaults.

That distinction compounds with the browser-engine point above: a script running on this MacBook can potentially see a distinctive font list through whichever browser you're using, then combine it with an engine-specific canvas or WebGL signature that a phone, locked to one shared engine across every app, simply cannot produce in the same way.⁵

Test Your Safari Fingerprint on iOS 26

Run the fingerprint inspector above on an iPhone running iOS 26 and compare the entropy score against a backup taken on an earlier version, and Apple's Advanced Fingerprinting and Tracking Protection (AFP) becomes visible directly in the numbers. AFP activates automatically for every user who upgrades to iOS 26, without requiring any settings changes.

AFP targets the highest-entropy passive signals that fingerprinting scripts rely on: canvas rendering output is modified to reduce uniqueness, WebGL output is altered, audio processing results are normalized, and font access is restricted to a common subset.¹ Consequently, a browser that previously produced a distinctive canvas hash on iOS 17 produces a modified output on iOS 26 Safari, making cross-session re-identification through canvas fingerprinting significantly harder.

Building on this, AFP differs from approaches taken by Brave and Firefox: rather than randomizing values per origin, AFP normalizes them toward a common baseline, which reduces intra-user variance while preserving the appearance of consistent behavior. Checking your own score above after the upgrade shows the reduction directly, instead of taking the description on faith.

What AFP in iOS 26 blocks and modifies

AFP modifies canvas and WebGL rendering output to reduce the uniqueness of the rendered result. Scripts calling HTMLCanvasElement.toDataURL() receive a modified pixel buffer that has been processed to reduce the hardware-specific variation caused by GPU drivers and font rasterizers. WebGL rendering output undergoes similar modification, reducing the fingerprinting value of canvas-based WebGL renders. Audio processing output through OfflineAudioContext is normalized; the floating-point values in the rendered audio buffer are adjusted to reduce DAC-specific variation.²

What AFP changes on iOS Safari

Font access is restricted to a predefined common subset, which prevents the font enumeration technique from producing a distinctive font list.¹ Consequently, the four highest-entropy passive fingerprinting signals are each reduced in entropy simultaneously. Building on this, AFP activates automatically and requires no user action; the protection is present from the first Safari launch after upgrading to iOS 26, making it the broadest default-on deployment of anti-fingerprinting protection in any major browser.

You can measure the effect directly by running the inspector on an iOS 26 device and comparing the entropy score with the same device before the upgrade, or with an Android phone running the same sites. The canvas, WebGL, and audio rows should show lower variance on iOS 26 than on earlier versions, which confirms that AFP is changing the underlying values rather than only hiding them. Testing on both Wi-Fi and cellular also shows whether the network path changes the result.

What AFP does not protect against

AFP's normalization approach leaves several hardware and locale signals completely untouched, which means a determined fingerprinting script can still collect meaningful entropy from the values AFP does not modify. navigator.hardwareConcurrency reports the real CPU core count, which ties the reading to the chip generation: an A13 has six cores (two high-performance and four efficiency cores), while the older A10 has four.³ screen.width and screen.height remain reported at the logical CSS resolution, which varies across iPhone models with different display dimensions, and window.devicePixelRatio continues to report the display's actual pixel ratio without any modification.

How to test Safari protection

WebRTC behavior on iOS has restricted local IP exposure since iOS 15, when Apple introduced mDNS ICE candidates that replace real local IP addresses with randomly generated .local addresses, so WebRTC leaks are already addressed independently of AFP.⁴ Timezone and language signals remain unmodified. AFP also does not remove the need to test after an update, because site scripts can still combine the remaining values into a recognizable profile. Consequently, a complete fingerprint score in iOS 26 Safari will be lower than in earlier iOS versions but will not reach zero; the remaining unmodified signals still provide some entropy. Building on this, the practical effect is that canvas-based, audio-based, and font-based tracking across sessions becomes substantially harder, while lower-entropy corroborating signals like screen resolution and hardware concurrency remain available to fingerprinting scripts.

How iOS 26 AFP compares to Brave and Firefox

AFP, Brave's farbling, and Firefox's privacy.resistFingerprinting address the same fingerprinting signals through different mechanisms. AFP normalizes canvas and audio output toward a common baseline shared across many iOS 26 Safari users; the goal is to reduce the uniqueness of each device's output without randomizing it. Brave farbles canvas output per origin and per session with controlled noise; the goal is to prevent stable cross-site and cross-session linking by ensuring the hash changes each time. Firefox RFP intercepts the canvas API at the engine level and injects a session-consistent modification that degrades the hash without breaking canvas functionality.

Consequently, AFP reduces entropy by normalization toward a shared baseline, Brave reduces it through session-scoped randomization that changes the hash on every new site and session, and Firefox reduces it by engine-level intervention that modifies canvas output before the script ever receives the pixel data, each reflecting a fundamentally different philosophy about how to defeat stable fingerprint collection.⁵

Which approach matches your device

For a user who wants to minimize their fingerprint entropy score, Brave's approach produces the most aggressive reduction on desktop; AFP produces the most significant reduction on iOS without requiring any configuration. If you browse primarily on iPhone, upgrading to iOS 26 gives you meaningful protection with zero setup, while desktop users who want the strongest available protection should combine Brave with its Shields set to aggressive mode. The key difference is that AFP normalizes toward a shared baseline while Brave randomizes per session, so the protection mechanism that works best for you depends on whether you prioritize consistency or unpredictability in your browsing profile. Checking your entropy score on iOS 26 against an earlier backup makes the AFP reduction concrete rather than theoretical.

When to use this

Run the inspector above right after upgrading to iOS 26 to audit your Safari fingerprint, or use it to check whether AFP changes how CapyToolkit Browser Fingerprint Inspector reports signals on your specific iPhone.

Examples

iOS 17 Safari: canvas hash = a4d9c2e1... (hardware-specific GPU-rendered value, stable across sessions)

iOS 26 Safari with AFP: canvas hash = modified output (normalized, less distinctive, may still be consistent within a session but differs from the pre-AFP hardware-rendered hash)

AFP is enabled by default after upgrading to iOS 26. No action is required.

To verify or adjust: Settings > Safari > Privacy > Advanced Fingerprinting and Tracking Protection. The toggle is on by default.