Safari adds noise in Private Browsing and, since Safari 26.0, limits known fingerprinting scripts. What WebKit says it restricts, and what it doesn't.
"Does Safari block fingerprinting?" has a split answer. Safari does not make every user look identical, the way Tor Browser aims to, and it does not add noise to every site's API calls by default. According to WebKit's own release notes, it has two layers: extra protections in Private Browsing, introduced in Safari 17, and since Safari 26.0 a restriction on scripts that Safari classifies as known fingerprinting scripts.
Key Takeaways
- Safari 17.0 added "noise to fingerprintable web APIs" and blocking of known trackers and fingerprinting in Private Browsing, per WebKit's Safari 17.0 notes.
- Safari 26.0 stops known fingerprinting scripts from reliably reading APIs such as screen dimensions, hardware concurrency, SpeechSynthesis voices, Apple Pay capabilities, web audio readback and 2D canvas, per WebKit's Safari 26.0 notes.
- The same scripts are also stopped from setting long-lived script-written storage and from reading query parameters and
document.referrer. - The protection depends on a script being recognised as a known fingerprinting script. An unlisted script is not described as affected.
- Server-side signals such as your IP address and TLS handshake, and the browser engine's own identity, are outside what these notes cover.
Two Layers, Not One Switch
Defences against fingerprinting usually follow one of two ideas. Uniformity makes many users return identical values, as Firefox and Tor do with resistFingerprinting. Noise perturbs the output so a tracker cannot hold a stable value, as discussed in our canvas noise article; DuckDuckGo's browser mixes both.
WebKit's approach, as described in its posts, is different again: target the scripts that are known to fingerprint, and leave ordinary scripts alone. That keeps sites working, at the price of depending on a classification.
Layer One: Private Browsing (Safari 17)
WebKit's Safari 17.0 post lists the changes to Private Browsing. The ones relevant here are blocking for known trackers and fingerprinting, and noise added to fingerprintable web APIs. It also lists blocking of known tracking query parameters in links, mitigation for trackers that map subdomains to third-party IP addresses, and blocking of CNAME-cloaked trackers.
That post does not say how the noise is generated or which APIs receive it, so we do not claim any specifics. It also does not say these protections apply to regular, non-private windows. Treat them as a Private Browsing feature unless a WebKit page you read says otherwise.
Layer Two: Known Fingerprinting Scripts (Safari 26.0)
The Safari 26.0 notes describe a change that applies to scripts Safari recognises as fingerprinting scripts. For those scripts only:
| Restricted | Related deep-dive |
|---|---|
| Screen dimensions | Screen resolution fingerprinting |
| Hardware concurrency | Hardware concurrency and device memory |
| SpeechSynthesis voice list | Speech synthesis fingerprinting |
| Web audio readback | Audio fingerprinting |
| 2D canvas | Canvas fingerprint detection |
| Apple Pay payment capabilities, "and more" | — |
WebKit's wording is that these scripts are prevented "from reliably accessing" such APIs. The post does not say whether that means noise, a fixed value or an empty result, so we won't guess. Two further restrictions go beyond API reads: known fingerprinting scripts cannot set long-lived script-written storage such as cookies or LocalStorage, and cannot read state used for navigational tracking, namely query parameters and document.referrer.
What Safari's Approach Leaves Open
- Unlisted scripts. Because the rule keys on classification, a script Safari has not classified is not described as restricted. A site's own first-party code that has never been flagged is the obvious case.
- Network-level signals. Your IP address and the TLS handshake are visible to every server regardless of browser; see TLS fingerprinting explained.
- Engine identity. A site can still tell it is talking to WebKit, and on iPhone that is true of every browser. We would not assume Chrome or Firefox on iOS inherit Safari's privacy settings; the WebKit posts cited here do not say so.
- State-based tracking is a separate layer. Intelligent Tracking Prevention deals with cookies, storage and referrers, not with computed fingerprints.
Keep stability in mind too: a fingerprint only helps a tracker while it stays the same, and real-world fingerprints drift on their own as browsers update and settings change, as covered in how fingerprints decay over time.
Test It Yourself
Open our fingerprint check in a normal Safari window, then in a Private window, and compare which values appear and whether any change between reloads. BrowserInsight is a first-party page and collects everything in your browser, so the "known fingerprinting script" rules are not expected to apply to it. The tool shows what a page can read; it does not report whether Safari's protections are active, and you draw that conclusion yourself. For the background on the techniques, read browser fingerprinting explained.
Frequently Asked Questions
Does Safari block fingerprinting completely?
No. WebKit describes restrictions on known fingerprinting scripts and extra protections in Private Browsing, not a blanket guarantee.
Is Safari's protection on in normal browsing?
The Safari 26.0 notes describe the known-script restrictions without limiting them to Private Browsing. The Safari 17.0 additions are listed specifically under Private Browsing.
Does Safari make my fingerprint identical to other users'?
Nothing in the cited WebKit posts says so. The stated goal is to stop known scripts from reliably reading device characteristics.
