cookiestatus.com

Browser privacy reference

How browsers handle cookies, storage and tracking

Cookie Status compares the tracking protections that the major browsers apply by default. It covers standard browsing only, not private or incognito modes or settings the user has to change.

  • 5 browsers
  • 10 features compared
  • updated 2026-10-31
http
# tracker.example, embedded on news.example
HTTP/2 200
set-cookie: uid=8f3a; Max-Age=31536000;
            SameSite=None; Secure

# what each browser does with it
brave    partitioned
chrome   no restrictions
edge     limited
firefox  partitioned
safari   blocked

$ curl -sI https://www.cookiestatus.com \
    | grep -i set-cookie
# no output: this site sets no cookies

Comparison

Current status

last_updated: · Added tracker blocking and fingerprinting rows, Safari 27 identity resolution blocking, and corrections for Brave, Edge and Safari from new tests.

Blocked
Access is denied by default.
Limited
Allowed with restrictions, such as shorter lifetimes or rules that only apply to known trackers.
No restrictions
The browser doesn't restrict this beyond standard web platform behavior.
Partitioned
Access is allowed, but kept separate for each top-level site, so it can't be used to follow the user across sites.
Unverified
The current claim hasn't been confirmed by testing or official documentation.
Brave ChromiumChrome ChromiumEdge ChromiumFirefox GeckoSafari WebKit
MechanismShieldsn/aTracking preventionEnhanced Tracking Protection (ETP)Intelligent Tracking Prevention (ITP)
Deployed in0.55.18n/a78.0.276.869.0Safari 11
Default protection modeDefault Shield settingsn/aBalancedStandardITP enabled
Latest releaseRelease notesRelease notesRelease notesRelease notesRelease notes
Classification of "known trackers" How does the browser decide which domains are trackers?
  • Filter lists: EasyList, EasyPrivacy, uBlock Origin lists and Brave’s own lists.
Sources (1) · 2026-10-31
Details
  • n/a
Details
  • Disconnect.me lists, delivered as Trust Protection Lists, with organization and engagement mitigations. New
Sources (1) · 2026-10-31
Details
  • Disconnect.me
Sources (1) · 2026-10-31
Details
  • Algorithmic
Details
Blocking of known trackers Does the browser stop requests to known trackers or fingerprinting scripts from loading at all?Blocked
  • Third-party requests that match the filter lists are blocked, including ads, trackers, cryptominers and known fingerprinting services. New
  • Requests that are same-site with the page are not blocked. New
  • Some blocked scripts are replaced with harmless stand-ins so the page keeps working. New
Sources (2) · 2026-10-31
Details		No restrictions
  • Requests to known trackers are not blocked. New
Checked · 2026-10-31
Details		Limited
  • Requests to known cryptominers and fingerprinters are blocked, even on sites the user engages with. New
  • Fingerprinters that are only on Disconnect.me’s Fingerprinting list, and in no other category, are not blocked. New
  • Other known trackers still load, but without storage access. New
Sources (1) · 2026-10-31
Details		Limited
  • Requests to the most common social media trackers (Facebook, Twitter and LinkedIn), cryptominers and known fingerprinters are blocked. New
  • Other tracking content, such as ads and embedded videos, still loads, but its cross-site tracking cookies are blocked. New
Sources (1) · 2026-10-31
Details		Limited
  • Cross-site requests to identity resolution (“ID graph”) services are blocked. Safari 27+ New
  • Navigations and same-site requests to these services are not blocked. Apple maintains the list and doesn’t publish it. Safari 27+ New
  • Other known trackers are not blocked. ITP restricts their storage instead.
Sources (2) · 2026-10-30
Details
Cookies in 3rd party context Can a site embedded on another site read and write its cookies?Partitioned
  • Not sent in cross-site subresource requests.
  • Partitioned access in frame.
  • Partitioned storage is cleared shortly after the user leaves the site (closes all its tabs), or when the browser is closed.
Sources (2) · 2026-10-31
Details		No restrictions
  • Third-party cookies are allowed. Google has dropped its plan to restrict them by default, and retired most other Privacy Sandbox technologies in October 2025. New
  • Opt-in mechanism (CHIPS) for partitioning cookies in 3P context.
  • Supports the Storage Access API, which matters mostly where third-party cookies are blocked. Chrome 119+ New
  • Cookies restricted to a maximum lifetime of 400 days.
Sources (4) · 2026-10-31
Details		Limited
  • Access blocked for known trackers, unless the user engages with the tracker’s site or organization.
  • Opt-in mechanism (CHIPS) for partitioning cookies in 3P context.
  • Supports the Storage Access API, which matters mostly where third-party cookies are blocked. New
  • Cookies restricted to a maximum lifetime of 400 days. New
Sources (4) · 2026-10-30
Details		Partitioned
  • Access restricted for known trackers.
  • Cookies are partitioned between the site and the third-party. Cookies are not shared across sites.
  • Supports the Partitioned attribute (CHIPS), although third-party cookies are partitioned anyway. Firefox 141+ New
  • Embedded content can ask for unpartitioned cookies with the Storage Access API. Firefox only prompts once an origin has asked on several sites, and denies requests if the user hasn’t used the site as a first party in the last 30 days. New
Sources (4) · 2026-10-31
Details		Blocked
  • All access restricted, except with Storage Access API. Safari prompts the user for each embedded site, and grants expire after 30 days of browser use without interaction.
  • Opt-in mechanism (CHIPS) for partitioning cookies in 3P context. First shipped in Safari 18.4, removed in 18.5, back in 26.2. Safari 26.2+ New
  • Temporary compatibility fix: if a site opens a third party in a pop-up and the user interacts with it, the third party gets cookie access when embedded on that site. New
Sources (5) · 2026-10-30
Details
Cookies in 1st party context Are the site's own cookies deleted or capped?Limited
  • Maximum expiry of about 6 months, for cookies set with both document.cookie and Set-Cookie. New
Sources (1) · 2026-10-30
  • Cookie Status test, Brave 1.97
Details		Limited
  • Cookies restricted to a maximum lifetime of 400 days.
Sources (1) · 2026-10-31
  • Cookie Status test, 2026-10-31
Details		Limited
  • Cookies restricted to a maximum lifetime of 400 days. New
Sources (1) · 2026-10-30
  • Cookie Status test, Edge 155
Details		Limited
  • All storage is purged from known trackers daily, unless the user has interacted with the site in first-party context within the last 45 days.
Details		Limited
  • For cookies set with document.cookie, deletion happens after 7 days of browser use without user interaction on the site.
  • For cookies set with document.cookie, expiration set to 24 hours on pages with URL decoration (query parameters or fragments) when referring domain is a known tracker.
  • If ITP classifies a domain as a tracker and the user hasn’t interacted with it as a first party in 30 days of browser use, all its site data is deleted, including cookies set with Set-Cookie. New
Sources (1)
Details
Other browser storage in 3rd party context Can embedded content use localStorage, IndexedDB and similar storage?Partitioned
  • Partitioned access in frame.
  • Partitioned storage is cleared shortly after the user leaves the site (closes all its tabs), or when the browser is closed.
Sources (2) · 2026-10-31
Details		Partitioned
  • Chrome partitions third-party storage.
  • The HTTP cache is partitioned by top-level site, so cached files can’t be used to track across sites. Chrome 86+ New
Sources (2) · 2026-10-31
Details		Partitioned
  • Access blocked for known trackers, with the same mitigations as cookies.
  • Storage of other domains is partitioned. New
Sources (2) · 2026-10-30
Details		Partitioned
  • localStorage and IndexedDB restricted for known trackers.
  • sessionStorage is not restricted.
  • Storage is partitioned between the site and the third-party. Storage is not shared across sites.
  • Network state, including the HTTP cache, is partitioned by top-level site. Firefox 85+ New
Sources (2) · 2026-10-31
Details		Partitioned
  • localStorage is partitioned and reset between application launches.
  • IndexedDB is partitioned and cleared when Safari quits. New
  • sessionStorage is partitioned.
  • The HTTP cache for third-party content is partitioned by top-level site. New
Sources (2) · 2026-10-30
Details
Other browser storage in 1st party context Is the site's own non-cookie storage deleted or capped?No restrictions
  • No restrictions.
Details		No restrictions
  • No restrictions.
Details		No restrictions
  • No restrictions.
Details		Limited
  • All storage is purged from known trackers daily, unless the user has interacted with the site in first-party context within the last 45 days.
Details		Limited
  • All script-writable storage is deleted after 7 days of browser use without interaction (click, tap, text input) with the site.
  • Web apps added to the Home Screen keep their own count of days of use, so their first-party data isn’t expected to be deleted. New
Sources (1)
Details
CNAME cloaking Does the browser see through a first-party subdomain that points to a third-party service?Blocked
  • Brave blocks any network requests where either the requested URL or that URL’s CNAME record matches any rules in Brave’s blocklists.
Details		No restrictions
  • No restrictions.
Details		No restrictions
  • No restrictions.
Details		No restrictions
  • No restrictions.
Details		Limited
  • Expiration of cookies set with Set-Cookie HTTP response headers is 7 days at most, if the response originates from a subdomain that has a CNAME alias to a cross-site origin, or if the subdomain is configured with A/AAAA records where the first half of the IP address does not match the first half of the IP address of the website the user is currently browsing.
  • Cookies set by the response to a top-level navigation are not capped, even if the site’s own hostname is a CNAME to another domain, such as a hosting provider. Safari 27.2+ New
Sources (2) · 2026-10-31
Details
Fingerprinting Does the browser change or hide the values scripts use to fingerprint the device?
  • Randomizes values from APIs used for fingerprinting, such as canvas. The random seed changes per site and per session. New
  • Blocks browser-language and font fingerprinting. New
  • Freezes the macOS version to 10_15_7 in the User-Agent string.
Sources (3) · 2026-10-31
Details
  • The User-Agent string is reduced: the minor version, platform version and device model are frozen. Sites can ask for the details through User-Agent Client Hints. New
  • Freezes the macOS version to 10_15_7 in the User-Agent string.
Sources (2) · 2026-10-31
Details
  • Requests to known fingerprinters are blocked (see Blocking of known trackers). New
  • Freezes the macOS version to 10_15_7 in the User-Agent string.
Sources (2) · 2026-10-31
Details
  • Limits how much information about the device and browser is revealed to sites. Mozilla says this makes about 14% fewer users uniquely identifiable, and about 49% fewer on macOS. Firefox 151+ New
  • Requests to known fingerprinters are blocked (see Blocking of known trackers). New
  • Freezes the macOS version to 10.15 in the User-Agent string.
Sources (2) · 2026-10-31
Details
  • No noise is added to fingerprinting APIs such as canvas: the canvas fingerprint was the same across sites and restarts. Safari 26 New
  • Freezes the macOS version to 10_15_7 in the User-Agent string.
Sources (2) · 2026-10-31
  • Cookie Status test, Safari 26
  • Cookie Status test, 2026-10-31
Details
Referrer How much of the previous page's URL is shared with other sites?
  • strict-origin-when-cross-origin or stricter referrer policy in subresource requests and cross-site navigational requests. Sites can’t loosen it: with unsafe-url, only the origin is sent.
  • Same-site navigation preserves the referrer.
Sources (1) · 2026-10-31
  • Cookie Status test, 2026-10-31
Details
  • Default browser policy (strict-origin-when-cross-origin)
  • Sites can loosen the policy: with unsafe-url, the full URL is sent to other sites. New
Sources (1) · 2026-10-31
  • Cookie Status test, 2026-10-31
Details
  • Default browser policy (strict-origin-when-cross-origin)
  • Sites can loosen the policy: with unsafe-url, the full URL is sent to other sites. New
Sources (1) · 2026-10-31
  • Cookie Status test, 2026-10-31
Details
  • Default browser policy (strict-origin-when-cross-origin or stricter)
  • Sites can’t loosen it for cross-site requests: with unsafe-url, only the origin is sent. New
Sources (1) · 2026-10-31
  • Cookie Status test, 2026-10-31
Details
  • Default browser policy (strict-origin-when-cross-origin)
  • In third-party requests (images, scripts, frames), the referrer is always cut to the origin, also in document.referrer. New
  • In navigations, sites can loosen the policy: with unsafe-url, the full URL is sent to other sites. New
  • For referrers that are known trackers, where the referring page also has URL decoration (query parameters or fragments), document.referrer is downgraded to eTLD+1.
Sources (2) · 2026-10-31
Details
Other Other protections that affect tracking and measurement.
  • Remove known tracking parameters (fbclid, gclid, msclkid, mc_eid, and others) from URL query strings.
  • Skip known bounce-tracking domains in links and go straight to the destination (debouncing). New
Sources (2) · 2026-10-31
Details
  • n/a
Details
  • n/a
Details
  • n/a
Details
  • Detect delays in bounce trackers and treat them as regular bounces.
  • Extend WebKit’s tracking protections to all browsers running on iOS 14 and newer. These protections can only be disabled by the user.
  • Purge all site data from classified domains if no user interaction (or Storage Access API grant) in first-party context has been recorded in the last 30 days.
  • Safari hides the user’s IP address in requests sent to known trackers.
  • Private Click Measurement, a privacy-preserving API for measuring ad clicks, is on by default. New
Sources (2)
Details

Claims marked New changed in the latest update. Follow Details → in any cell for the full explanation on that browser's page.

History

Latest changes

all changes → · rss

  1. Safari

    Safari 27.2 stops capping cookies on CNAME-hosted sites

    Cookies set by the response to a top-level navigation are no longer capped at 7 days when the site’s own hostname is a CNAME to another domain, such as a hosting provider.

    affects: cname cloaking · source: WebKit Features for Safari 27.2

  2. Safari

    Safari 27 blocks identity resolution services

    Cross-site requests to “ID graph” services, which link the same person across sites and devices, are blocked whenever “Prevent cross-site tracking” is on. Apple maintains the list of domains.

    affects: tracker blocking · source: Blocking identity resolution infrastructure (WebKit blog)

  3. Firefox

    Firefox 151 adds fingerprinting protection to Standard mode

    Firefox limits how much information about the device and browser is revealed to sites in its default mode, not only in Strict mode.

    affects: fingerprinting · source: Firefox 151 release notes

  4. Safari

    CHIPS returns in Safari 26.2

    Partitioned cookies with the Partitioned attribute are supported again, after being removed in Safari 18.5 for further work.

    affects: 3rd-party cookies · source: WebKit Features in Safari 26.2

  5. Chrome

    Google retires most Privacy Sandbox technologies announced

    Topics, Protected Audience, Attribution Reporting, Related Website Sets and others are being phased out. CHIPS and FedCM stay.

    affects: 3rd-party cookies · source: Update on plans for Privacy Sandbox technologies

FAQ

1. Why does this resource exist?

Web browsers are going through fairly momentous shifts in order to better respond to the increasing number of data breaches and cases of data misuse by third parties.

Unfortunately, each browser (and the underlying browser engine) seems to have their own interpretation of how to best tackle the problem, which leads to a diverse set of features across the browser landscape.

What’s worse, the information about how these tracking protection mechanisms are deployed is all over the place: in release notes, in developer documentation, in Twitter threads, in working groups, in feature drafts, in bug patches, etc.

The purpose of the Cookie Status resource is to (attempt to) collect this information in one place for easy access and perusal.

There is no commercial agenda behind this project. In fact, there is no agenda other than knowledge transfer.

2. Why only these browsers?

Just to kick things off. Hopefully the open-source nature of this project will invite others to contribute details about browsers that are doing significant work with regard to user privacy.

3. What cookies / browser storage does Cookie Status set and why?

Cookie Status doesn’t use browser cookies, localStorage, or IndexedDB.

It doesn’t use sessionStorage either, and it doesn’t load anything from third-party servers. The search index is served from this site.

If you see anything contrary to the above, please raise an issue about this.